From jalocha@home-gate.ifj.edu.pl Sat Apr 01 06:27:49 1995
Received: from home-gate.ifj.edu.pl ([192.86.14.17]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id GAA18997 for <hfsig@tapr.org>; Sat, 1 Apr 1995 06:27:36 -0600
Received: from home.ifj.edu.pl by home-gate.ifj.edu.pl (JNOS1.10h) with SMTP
	id AA2140 ; Sat, 01 Apr 95 14:27:12 UTC
Date: Sat, 1 Apr 95 13:52:21 MET
From: "Pawel Jalocha" <jalocha@home.ifj.edu.pl>
Message-ID: <357.jalocha@home.ifj.edu.pl>
To: hfsig@tapr.org
Reply-to: jalocha@home-gate.ifj.edu.pl
Subject: Parallel carrier modem

Hello everybody,

At last I can report a success: I became less ambitious :-)
and let my parallel carrier modem do only BPSK on every carrier.
The whole thing began to work ! At least it passes right varying
bit patterns and the symbol clock converges right.

The modem runs now at 9600 Hz sampling, 128 point FFT with sin()^2
window at Tx and Rx. FFT steps are 32 samples with +/- 1 adjustments
for the receiver to synchronize it to the symbol clock.
Data carriers are spaced 150 Hz apart. Each carrier is BPSK modulated
with symbols (bits) spaced by 64 samples which makes 150 bits/sec.
There are 15 carriers: the first at 600 Hz and the last at 2700 Hz.
Total data rate is 2250 bps. No FEC coding yet.
Is this worth anything ?

Most of the above parameters can be easily adjusted: I can move
to 256 point FFT and 31 carriers immediately - more carriers very
likely need some tricks as I will run into my RAM limits.

The symbol timing and data carrier detection logic work somehow
although they need some tuning still. I have two different ideas
about how to make a tuning indicator - one of them must work :-).
In a short time I should have something useable for on-air operation.

I suspect there are still minor problems with inter-symbol crosstalks...
The way I attempt to cancel them is not the best one.
I could cure the problem by spacing the carriers by more Hz
- use every third carrier not every second.
The price: less carriers -> lower total bit rate.

Paul and others are certainly right that my carrier configuration
is too tide for an SSB tranceiver. But moving to 8000 Hz sampling
is not a problem - just one line in the source code.
Or I just use less carriers, although 15 or 31 carriers
is a good number for my primitive FEC code.
24 is good for the Golay code.

At same time I am thinking about the non-coherent modulation,
and I can't see a good solution for the problem of finding
the threshold for 0/1 decisions. With BPSK the threshold is zero
regardless of carrier's amplitude, for carrier on/off modulation
the threshold can be potentially different for every carrier.

Pawel

From jalocha@home-gate.ifj.edu.pl Sat Apr 01 07:35:53 1995
Received: from home-gate.ifj.edu.pl (home-gate.ifj.edu.pl [192.86.14.17]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id HAA19225 for <hfsig@tapr.org>; Sat, 1 Apr 1995 07:35:45 -0600
Received: from home.ifj.edu.pl by home-gate.ifj.edu.pl (JNOS1.10h) with SMTP
	id AA2145 ; Sat, 01 Apr 95 15:35:16 UTC
Date: Sat, 1 Apr 95 15:08:35 MET
From: "Pawel Jalocha" <jalocha@home.ifj.edu.pl>
Message-ID: <361.jalocha@home.ifj.edu.pl>
To: hfsig <hfsig@tapr.org>
Reply-to: jalocha@home-gate.ifj.edu.pl
Subject: Re: [HFSIG:350] Overlapped Symbol windowing (Was HFSIG Activities)

Hello Paul,

> The result of adding 128pt sin()^2 shaped symbols, overlapped at 64 pts, of
> alternating phases (+/-90degrees = 180degree shifted) is the same as a 64pt
> sin() shaped signal. (Unless there is no phase shift which gives continuous
> tone). This is what my simulations produced. Is this correct, or Do I have a
> flaw in my data?

I think what you find is right.
I try to explain the point by the following (a bit naive) comparison:

 shaping #1: 128 pt, sin()^2
=============================

 bit pattern             waveform                 bandwidth

  0101010101      carrier*sin(2*pi*(1/128)*t)     2*(1/128)

  1111111111      pure carrier                    0
or 000000000


 shaping #2: 64 pt, sin()
==========================

 bit pattern             waveform                 bandwidth

  0101010101      carrier*sin(2*pi*(1/128)*t)     2*(1/128)

  1111111111    carrier*abs(sin(2*pi*(1/128)*t))  infinite ! (or at least
or 000000000                                      very large)


As you see the 64pt, sin() shaping generates a very wide signal
for a constant bit pattern thus you cannot say, that your energy
goes into the band assigned for that carrier.
The harmonics (due to "abs" function) will affect other carriers.

> Also, By shaping the symbols so that they are timewise independent, we may be
> able to use multiple phases when the channel is better, thus doubling
> (4phases=2bits) or tripling (8phases=3bits) or data rate? Although the protocol
> would have to detect and adjust for this?

I agree the 64pt sin() shaping makes the symbols time-independent,
but at the price of the bandwidth (thus frequency dependence).
Here is the comprimise to be taken...

Pawel

From karn@qualcomm.com Sat Apr 01 15:01:46 1995
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id PAA20920 for <hfsig@tapr.org>; Sat, 1 Apr 1995 15:01:43 -0600
Received: (karn@localhost) by servo.qualcomm.com (8.6.10/QC-BSD-2.5) id NAA28192; Sat, 1 Apr 1995 13:04:31 -0800
Date: Sat, 1 Apr 1995 13:04:31 -0800
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199504012104.NAA28192@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <357.jalocha@home.ifj.edu.pl>
Subject: Re: [HFSIG:351] Parallel carrier modem

>At same time I am thinking about the non-coherent modulation,
>and I can't see a good solution for the problem of finding
>the threshold for 0/1 decisions. With BPSK the threshold is zero
>regardless of carrier's amplitude, for carrier on/off modulation
>the threshold can be potentially different for every carrier.

This is only a problem with on-off keying, it is not inherent to
non-coherent demoduation. Ordinary FSK is noncoherent, for example.
So is m-ary FSK. You just look for the filter output with the greatest
amplitude.

Phil

From jalocha@home-gate.ifj.edu.pl Sat Apr 01 18:55:00 1995
Received: from home-gate.ifj.edu.pl (home-gate.ifj.edu.pl [192.86.14.17]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id SAA21933 for <hfsig@tapr.org>; Sat, 1 Apr 1995 18:54:10 -0600
Received: from home.ifj.edu.pl by home-gate.ifj.edu.pl (JNOS1.10h) with SMTP
	id AA2149 ; Sun, 02 Apr 95 03:53:10 UTC
Date: Sun, 2 Apr 95 02:16:07 MET
From: "Pawel Jalocha" <jalocha@home.ifj.edu.pl>
Message-ID: <364.jalocha@home.ifj.edu.pl>
To: hfsig <hfsig@tapr.org>
Reply-to: jalocha@home-gate.ifj.edu.pl
Subject: [HFSIG:353] Re: Parallel carrier modem

Phil wrote:

> This is only a problem with on-off keying, it is not inherent to
> non-coherent demoduation. Ordinary FSK is noncoherent, for example.
> So is m-ary FSK. You just look for the filter output with the greatest
> amplitude.

Right, but only if you take the assumption that your passband is flat.
I can see several reasons for the passband to be non-flat within
at least 6dB thus a "take the highest" decision may not be always
optimal. Ideally, you would monitor the levels on every carrier
and compute individual thresholds.
On the other hand I don't like the m-ary FSK as if somebody
puts on a dead carrier the whole trasmition is trashed.

Which way would you suggest for Walsh function type signaling
where you get many carriers turned on at a time ?

Pawel

From karn@qualcomm.com Mon Apr 03 01:06:40 1995
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id BAA28917 for <hfsig@tapr.org>; Mon, 3 Apr 1995 01:06:37 -0500
Received: (karn@localhost) by servo.qualcomm.com (8.6.10/QC-BSD-2.5) id XAA01986; Sun, 2 Apr 1995 23:09:25 -0700
Date: Sun, 2 Apr 1995 23:09:25 -0700
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199504030609.XAA01986@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <364.jalocha@home.ifj.edu.pl>
Subject: Re: [HFSIG:354] Re: Parallel carrier modem

>Right, but only if you take the assumption that your passband is flat.

So correct it if it's not flat. This is not a hard problem.

>On the other hand I don't like the m-ary FSK as if somebody
>puts on a dead carrier the whole trasmition is trashed.

Not at all. I have been thinking about this exact problem, and it turns out
that there's a simple solution.

First, scramble your data. That ensures that the probability of two
consecutive symbols (frequencies) being the same is 1/N, where N is the
number of distinct symbols/frequencies.

Second, the demod "copies behind". That is, it keeps a history of
several symbols worth of FFTs. If it sees a consistent strong signal
in one frequency bin, it attributes it to a strong in-band jammer and
ignores that channel until it disappears. I.e., it picks the
next-strongest channel as its output.

No real problem if the desired signal happens to hit on the jammer's
frequency since this will only happen with probability 1/N. Just pick
a FEC code strong enough to correct this many errors.

My thinking here is that with this scheme for suppressing
interference, the Walsh function layer may turn out to be unnecessary.

Proper choice of a window for the FFT will be important,
though. Rejecting a very strong inband CW interferer requires a window
with low sidelobes, but windows with this property also broaden the
mainlobe. This may mean more bandwidth than would otherwise be
required for 1/T orthogonality.

Phil
From JALOCHA@chopin.ifj.edu.pl Wed Apr 05 07:29:00 1995
Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id HAA14399 for <hfsig@tapr.org>; Wed, 5 Apr 1995 07:28:45 -0500
From: JALOCHA@chopin.ifj.edu.pl
Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cyf-kr.edu.pl (8.6.11/8.6.11) with SMTP id OAA29418 for <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>; Wed, 5 Apr 1995 14:25:56 +0200
Date: Wed, 5 Apr 1995 14:27 GMT+1
Subject: Re: [HFSIG:355] Re: Parallel carrier modem
To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>
Message-id: <E9DDF4DC00A038C3@chopin.ifj.edu.pl>
X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org
X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>"


>Second, the demod "copies behind". That is, it keeps a history of
>several symbols worth of FFTs. If it sees a consistent strong signal
>in one frequency bin, it attributes it to a strong in-band jammer and
>ignores that channel until it disappears. I.e., it picks the
>next-strongest channel as its output.

OK, but the algorythm should be enchanced so it can pick up more than one
jammer :-)

Walsh function approach looks efficiant to me in this respect: if I have
128 or 256 carriers I can remove say 4 strongest ones and still be able
to decode the symbol. An alternative approach would be to compute the
average of all carriers and then remove carriers above 3 times the
average or so.

Pawel
From JALOCHA@chopin.ifj.edu.pl Wed Apr 05 08:05:48 1995
Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id IAA14508 for <hfsig@tapr.org>; Wed, 5 Apr 1995 08:04:58 -0500
From: JALOCHA@chopin.ifj.edu.pl
Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cyf-kr.edu.pl (8.6.11/8.6.11) with SMTP id PAA29775 for <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>; Wed, 5 Apr 1995 15:02:22 +0200
Date: Wed, 5 Apr 1995 15:03 GMT+1
Subject: Re: [HFSIG:351] Parallel carrier modem
To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>
Message-id: <EEEFB45EC0A038C3@chopin.ifj.edu.pl>
X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org
X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>"


It's time to say something about my progress with the parallel-carrier
BPSK modem:

The design of using minimal carrier spacing turned out to be
rather unstable. It did work but crosstalks across time and frequency
made the symbol-sync not very stable in low S/N.
My attempts to cancel the crosstalk made the symbol-sync
even less stable...

So I decided to use every third carrier, not every second one.
In such configuration, with sin(x)^2 window the crosstalk across
carriers is zero. There is still left a crosstalk of 1/6 across
symbols on same carrier, but the modem was behaving far better
- I can say it was "useable".

So now the modem does 8000 Hz sampling, 128 point FFT.
Data carriers are spaced at 3*(8000/128) = 187.5 Hz
each carrier is modulated with BPSK at 125 bps (64 points
between symbols).
I use 12 carriers which fit into the "standard" audio passband.

I am playing with two shaping windows (Tx and Rx use identical windows):

1. sin(x)^2, x=0..pi
   => freq. crosstalk = 0, time crosstalk=1/6

2. 3/4*sin(x)-1/4*sin(3*x), x=0..pi
   => freq. crosstalk = 1/20, time crosstalk=1.7/20

The second window works a bit better.
I don't try any more canceling the crosstalks - I just leave it as it is.

I tested the modem only in loopback mode. To check the behaviour in low
S/N I was adding some noise from my HF receiver phone-jack.
The bit-sync and DCD is stable up to very low S/N when you can hardly hear
the tones in the noise.
I have made up a KISS interface to the modem so now it is a useable
KISS TNC. Somebody willing to play with it ? Note that the modem works
on a DSPCARD4.

I still see a little problem with symbol-sync: it's a bit slow
and needs TxDelay time of about 50 (500 ms).

I tried to come back to QPSK with "every third carrier design":
the bit-sync locks up and the data looks almost OK but there
are single flipped bit.

I plan to double the number of carriers to 24 and then add a Golay FEC code
with interleave to see how it improves the copy.
I only need to write Golay routines which don't take up too much space
for decoding tables, so it all fits into my DSPCARD4 RAM.

Pawel
From karn@qualcomm.com Wed Apr 05 12:54:45 1995
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id MAA17309 for <hfsig@tapr.org>; Wed, 5 Apr 1995 12:54:40 -0500
Received: (karn@localhost) by servo.qualcomm.com (8.6.10/QC-BSD-2.5) id KAA06366; Wed, 5 Apr 1995 10:57:28 -0700
Date: Wed, 5 Apr 1995 10:57:28 -0700
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199504051757.KAA06366@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <E9DDF4DC00A038C3@chopin.ifj.edu.pl> (JALOCHA@chopin.ifj.edu.pl)
Subject: Re: [HFSIG:356] Re: Parallel carrier modem

The algorithm is easily extended to handle several strong jammers, limited
by two things: the FFT window sidelobes and the strength of the FEC.

Phil
From jalocha@home-gate.ifj.edu.pl Mon Apr 10 10:39:11 1995
Received: from home-gate.ifj.edu.pl (home-gate.ifj.edu.pl [192.86.14.17]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id KAA24941 for <hfsig@tapr.org>; Mon, 10 Apr 1995 10:38:43 -0500
Received: from home.ifj.edu.pl by home-gate.ifj.edu.pl (JNOS1.10h) with SMTP
	id AA2257 ; Mon, 10 Apr 95 18:38:23 UTC
Date: Mon, 10 Apr 95 17:37:20 MET
From: "Pawel Jalocha" <jalocha@home.ifj.edu.pl>
Message-ID: <310.jalocha@home.ifj.edu.pl>
To: hfsig@tapr.org
Reply-to: jalocha@home-gate.ifj.edu.pl
Subject: Proposal for a picollo-type modulation scheme

Last weekend I was doing some calculations about the performance
of various modulations and the picollo-type modulation came out
to be a clear winner. My thoughts drifted towards m-ary FSK
and I have here a proposition for a picollo system:

I am bounded to my DSP system so just to fix some numbers
and to show the relations between them here is the characteristic
of the FFT which is the base for modulator/demodulator:

Sampling rate: 8000 Hz.
FFT size: 256 samples -> 128 frequency bins.
FFT window: sin(x)^2 for x = 0..pi.
FFT would be done in overlaping steps of 64 samples
Symbol length = 256 samples
Inter-symbol spacing = 128 samples (crosstalk = 1/6).
Symbol rate = 8000/128 = 62.5 Hz
Inter-carrier spacing = 2 freq. bins (crosstalk = 1/6) = 2*(8000/256) = 62.5 Hz
Carriers used: 32 - > total bandwitdh = 32*2*(8000/256) = 2000 Hz.
Bits per symbol: 5 -> raw bit rate = 5*62.5 = 375 bps.

Tuning is a real problem with these HF modems.
If you get a radio with 1Hz resolution and stability this may seem not
to be a problem but at least with my rig which has the tuning resolution
of 10Hz and the stability of +/- 50-100 Hz this is a problem.
Even making a tuning indicator which tells you the de-tune within a single
carrier is not enough is most cases.

To let the receiver auto-tune to the incoming signal at the beginning
of a transmition we send a special signal: a ramp-up followed by
a ramp-down, like this: (an example for 8 carriers)

Carrier
|
7        *
6       * *
5      *   *
4     *     *
3    *       *
2   *         *
1  *           *
0 *             *
  01234567 -------->  symbol

For my FFT setup with 32 carriers this would take 63 symbols
which is a bit more than one second.

The receiver would hunt for ramp-up and ramp-down at same time
and if a coincidence of both is found within the expected time
the receiver is able to determine the band edges.

Note that the Rx doesn't need to find a complete ramp to determine
the edges, it's enough if it finds one piece of the ramp-up
and another piece of the ramp-down.
Because the ramps span the whole band there is minimal chance
that narrowband interferences would prevent the receiver
from detecting and measuring them.

Not only the band edges can be determined but the symbol timing
can be found as well. Thus after detecting the sync. signal
we are tuned and synchronized.

We can use the sync. for one more purpose:
to fix the FEC block timing. Our FEC coding needs the data to be sent
in blocks thus the receiver should know where are the block's edges.
The moment when the ramp changes the direction can be considered
as the mark point: 32 symbols later, when the ramp-down is complete,
the first FEC block would start.

The sync. signal could be repeated several times if needed.
In this case a nice size for the FEC block would be 2*32 = 64 symbols
(this makes 320 bits or 40 bytes) - then whatever sync.
we acquire, we will get synchronized to the FEC block timing.

Infact, this ramp-up, ramp-down series can be the base for the "scrambling"
algorythm. That is if we send all zeros (NULL characters), the sygnal
follows this series.

As you see from my FFT characteristics I "oversample" the signal by two
both in time and in frequency. I think it should be possible to interpolate
the points if we found that we are de-tuned by half or a quarter of a carrier.
Same about the symbol timing shift. This should save the trouble with making
the sliding FFT with time-adjust capability.

The way to hunt for ramps: I am going to try summing up energies
along diagonals, like this:

Carrier
|
7               abc
-              abc
6             abc
-            abc
5           abc
-          abc
4         abc
-        abc
3       abc
-      abc
2     abc
-    abc
1   abc
-  abc
0 abc
  0-1-2-3-4-5-6-7 -------->  symbol

"-" = the "oversampled" points.
"a" = points to be summed into A
"b" = points to be summed into B
"c" = points to be summed into C

If I find B>noise and B>A and B>C I assume the ramp-up is around B
and I get it's fine position Tu but interpolating with A and C.

Similar way for ramp-down: I find it's fine time Td.

If I see Td - Tu = 8 symbols (+/-tune-error) I compute:

Tu := Tu + 8 Symbols
Tune_correction = (Tu - Td)/2
Symbol_time = (Tu + Td)/2

Little associated ideas:

- Use Gray code - in a rather probable case that a particular symbol
"moves" to the adjacent carrier due to receiver mistune or instability
or the Doppler shift or anything, this will result in corruption
on one bit only.

- Band equalization: I think it is enough to adjust the gains for every
frequency bin such that the RMS of the outcoming signal is same
for all bins. This should minimize destructive effects coming from
dead carriers and CWs.

So what do others think of the whole idea ?

I am going to write some code for detecting the sync. to see how it
behaves with low S/N.

Pawel




From kurpiers@zeus.uet.e-technik.th-darmstadt.de Mon Apr 10 11:41:43 1995
Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id LAA25468 for <hfsig@tapr.org>; Mon, 10 Apr 1995 11:41:26 -0500
Received: from zeus (zeus.uet.e-technik.th-darmstadt.de) by rs2.hrz.th-darmstadt.de with SMTP id AA33953
  (5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Mon, 10 Apr 1995 18:40:57 +0200
Received: from hades (hades.uet.e-technik.th-darmstadt.de [130.83.18.78]) by zeus (8.6.9/8.6.9-HRZ) with ESMTP id SAA21605 for <hfsig@tapr.org>; Mon, 10 Apr 1995 18:40:56 +0200
From: Alexander Kurpiers <kurpiers@zeus.uet.e-technik.th-darmstadt.de>
Received: (kurpiers@localhost) by hades (8.6.9/8.6.9-HRZ-Fwd2.0) id SAA21519 for hfsig@tapr.org; Mon, 10 Apr 1995 18:36:48 +0200
Message-Id: <199504101636.SAA21519@hades>
Subject: Re: [HFSIG:359] Proposal for a picollo-type modulation scheme
To: hfsig@tapr.org
Date: Mon, 10 Apr 1995 18:36:48 +0200 (MESZ)
In-Reply-To: <310.jalocha@home.ifj.edu.pl> from "Pawel Jalocha" at Apr 10, 95 10:45:05 am
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 3349      

Pawel wrote:
> 
> Last weekend I was doing some calculations about the performance
> of various modulations and the picollo-type modulation came out
> to be a clear winner. My thoughts drifted towards m-ary FSK
> and I have here a proposition for a picollo system:

I is clear that m-ary FSK is better than i.e. OFDM, but you trade
bandwidth for S/N. I believe that a modulation scheme with parallel
orthogonal carriers (OFDM) and a decent coding will be better in
overall performance (taking into account that the symbol time is
limited to about 10ms due to multipath and thus to achieve high
bitrate you have to use many many carriers in MFSK).

> 
> I am bounded to my DSP system so just to fix some numbers
> and to show the relations between them here is the characteristic
> of the FFT which is the base for modulator/demodulator:
> 
> Sampling rate: 8000 Hz.
> FFT size: 256 samples -> 128 frequency bins.
> FFT window: sin(x)^2 for x = 0..pi.
> FFT would be done in overlaping steps of 64 samples
> Symbol length = 256 samples
> Inter-symbol spacing = 128 samples (crosstalk = 1/6).
> Symbol rate = 8000/128 = 62.5 Hz
> Inter-carrier spacing = 2 freq. bins (crosstalk = 1/6) = 2*(8000/256) = 62.5 Hz
> Carriers used: 32 - > total bandwitdh = 32*2*(8000/256) = 2000 Hz.
> Bits per symbol: 5 -> raw bit rate = 5*62.5 = 375 bps.

With 32 carriers and 4DQPSK on each of them you would have 4000bps. Of
course the S/N would degrade the performance of such a modulation scheme,
I think you can win back a lot with coding. But to occupy a whole SSB
channel for 375bps uncoded data is too inefficient.

The next problem is the robustness of such a system. I believe if one or
more frequency bins fade out because of frequency selective fading you are
in trouble. You would at least have to do some kind of interleaving to
overcome these effects.

In the OFDM case we have several possible solutions. If we know the channel
capacity of each bin or carrier there is a solution (water pouring) how
to distribute the transmit power over the carriers. This implies that there
is some back channel from the demodulator at the RX side to the TX side. This
is possible in an ARQ system. If there is no such channel it is still
possible to achieve a reasonable throughput by interleaving the information
on the carriers, so that each virtual "carrier" carries the same mean
information.
The third possibility is the application of broadband signals, OCDM
(= orthogonal code division multiplex). I've read through an interesting
article on this topic recently (J. Lindner, "Channel Coding and Modulation
for Transmission over Multipath Channels", to be published in 
no. 3 AEUe, May 1995). 
 

Alexander
-- 
*--------------------------------------------------------------*
|        Alexander F. Kurpiers                                 |
|        Institut fuer Uebertragungstechnik                    |
|        Merckstrasse 25                                       |
|        D-64283 Darmstadt (Germany)                           |
|        Voice: +49-6151-162369                                |
|        Fax  : +49-6151-165545                                |
|        EMail: kurpiers@zeus.uet.e-technik.th-darmstadt.de    |
|        Hamradio: dl8aau@db0kg.#nds.deu.eu                    |
*--------------------------------------------------------------*
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Hi,

My $0.02:

Alexander wrote:

]
]Pawel wrote:
]> 
]> Last weekend I was doing some calculations about the performance
]> of various modulations and the picollo-type modulation came out
]> to be a clear winner. My thoughts drifted towards m-ary FSK
]> and I have here a proposition for a picollo system:
]
]I is clear that m-ary FSK is better than i.e. OFDM, but you trade
]bandwidth for S/N. I believe that a modulation scheme with parallel
]orthogonal carriers (OFDM) and a decent coding will be better in
]overall performance (taking into account that the symbol time is
]limited to about 10ms due to multipath and thus to achieve high
]bitrate you have to use many many carriers in MFSK).
]
]> 
]> I am bounded to my DSP system so just to fix some numbers
]> and to show the relations between them here is the characteristic
]> of the FFT which is the base for modulator/demodulator:
]> 
]> Sampling rate: 8000 Hz.
]> FFT size: 256 samples -> 128 frequency bins.
]> FFT window: sin(x)^2 for x = 0..pi.
]> FFT would be done in overlaping steps of 64 samples
]> Symbol length = 256 samples
]> Inter-symbol spacing = 128 samples (crosstalk = 1/6).
]> Symbol rate = 8000/128 = 62.5 Hz
]> Inter-carrier spacing = 2 freq. bins (crosstalk = 1/6) = 2*(8000/256) = 
62.5 Hz
]> Carriers used: 32 - > total bandwitdh = 32*2*(8000/256) = 2000 Hz.
]> Bits per symbol: 5 -> raw bit rate = 5*62.5 = 375 bps.
]
]With 32 carriers and 4DQPSK on each of them you would have 4000bps. Of
]course the S/N would degrade the performance of such a modulation scheme,
]I think you can win back a lot with coding. But to occupy a whole SSB
]channel for 375bps uncoded data is too inefficient.
]
]The next problem is the robustness of such a system. I believe if one or
]more frequency bins fade out because of frequency selective fading you are
]in trouble. You would at least have to do some kind of interleaving to
]overcome these effects.
]



    Agreed: If we want to take advantage of reasonable conditions, 
    especially for networking, OFDM with appropiate coding 
    would be great.

    On the other hand, if we are interested in HF communications, no
    matter how adverse conditions may be, MFSK probably would be
    a better choice.

    Implementation of a resonable number of frequency slots, either
    for OFDM or MFSK may require a careful tradeoff in your algorithmic
    approach. I suspect there are further considerations when choosing 
    between a correlator appoach, as typically used for MFSK, or the 
    FFT approach as typically used by the OFDM. It is my opinion
    that the simplicity of a well-designed correlator, i.e., taking 
    advantage of decimated pre-processing, integrate/dump, and precision
    combiners, is superior in performance to an FFT approach - judged
    merely by roundoff errors and possible dynamic range. The catch is 
    that such a correlator takes a lot more code and cannot compete with 
    the efficiency of the FFT approach when it comes to a multitude of 
    channels.

    My guess, at least when considering our present fixed point DSP's
    is that MFSK will be limited to fewer channels - OFDM will handle
    more channels, however, will not be as robust.

    I think that there is merit for both approaches and would
    encourage experimentation in either - who knows, perhaps there is
    someone out there that has a solution to increasing the dynamic
    range of the FFT approach, or someone that have a solution
    to implementing efficient correlators over a multitude of
    channels. In my modest opinion, those are our present challenges. 

      
     
]In the OFDM case we have several possible solutions. If we know the channel
]capacity of each bin or carrier there is a solution (water pouring) how
]to distribute the transmit power over the carriers. This implies that there
]is some back channel from the demodulator at the RX side to the TX side. 
This
]is possible in an ARQ system. If there is no such channel it is still
]possible to achieve a reasonable throughput by interleaving the information
]on the carriers, so that each virtual "carrier" carries the same mean
]information.

]The third possibility is the application of broadband signals, OCDM
](= orthogonal code division multiplex). I've read through an interesting
]article on this topic recently (J. Lindner, "Channel Coding and Modulation
]for Transmission over Multipath Channels", to be published in 
]no. 3 AEUe, May 1995). 

    Alexander, perhaps you could give us a summary of what this
    involves - thanks.


73's, Johan KC7WW
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Alexander wrote:

>I is clear that m-ary FSK is better than i.e. OFDM, but you trade
>bandwidth for S/N. I believe that a modulation scheme with parallel
>orthogonal carriers (OFDM) and a decent coding will be better in
>overall performance (taking into account that the symbol time is
>limited to about 10ms due to multipath and thus to achieve high
>bitrate you have to use many many carriers in MFSK).

My opinion is that MFSK is the optimum choice for single HF channel working,
low-speed data. OFDM is for higher speed working. Both systems need to be
developed. Perhaps OFDM could be made to degenerate gracefully towards MFSK
in worsening channel conditions. If we think of OFDM as a number of
multiplexed MFSK channels, then these channels could be made to drop out
so that the same transmitter power becomes concentrated across a smaller
bandwidth thus gaining SNR.

Johan wrote:

>    Implementation of a resonable number of frequency slots, either
>    for OFDM or MFSK may require a careful tradeoff in your algorithmic
>    approach. I suspect there are further considerations when choosing 
>    between a correlator appoach, as typically used for MFSK, or the 
>    FFT approach as typically used by the OFDM. It is my opinion
>    that the simplicity of a well-designed correlator, i.e., taking 
>    advantage of decimated pre-processing, integrate/dump, and precision
>    combiners, is superior in performance to an FFT approach - judged
>    merely by roundoff errors and possible dynamic range. The catch is 
>    that such a correlator takes a lot more code and cannot compete with 
>    the efficiency of the FFT approach when it comes to a multitude of 
>    channels.

I have substituted a quadrature matched correlator type demodulator for the
FFT-based demodulator in my ADSP2101 MFSK modem and so far have found that the
Block Floating Point FFT with multiple stages of decimation is better. I do
the post-integration arithmetic in full floating point. I am not yet clear
as to why the correlator seems worse. The peak frequency bin is currently
selected by scanning the array of magnitude squared results, comparing
first the exponents of M(n), Mpeak, and setting Mpeak=M(n) if M(n)'s exponent
is greater. If the exponents are the same, the mantissas are compared in a
similar way. Perhaps this is not the best way of doing it. Any suggestions?

These are the figures for the matched correlator demodulator:

Input sample rate: 7680Hz
Input filter: 45 tap FIR fc=660Hz
Decimation: 1/3
Correlator sample rate: 2560Hz
sin/cos lookup table: 256 entries (FTF=10Hz)
frame buffer size: 128 (50ms)
M correlators (M is typically 12) executed at 320Hz rate (16 x per 50ms symbol)

The point is, MFSK based on FFT is not bad and is very efficient compared
to the matched correlator approach. It is also potentially upgradable in
real-time to OFDM. The crucial issues for the MFSK DSP system are: aliasing
and roundoff noise caused by demodulation to I/Q and decimation, FFT dynamic
range and tuning control.

The idea of trying the correlators at signalling frequencies, was to get rid
of the need for heavy decimation and quadrature demodulation ahead of the FFT,
considerably simplifying the processing and hopefully reducing aliasing noise.
So far, no advantage in doing this has been observed. Maybe I should try
substituting the FFT for a bank of floating point matched correlator detectors
which would offer more dynamic range compared to the CBFP FFT.

Perhaps we can try Pawel's suggestions of windowing and extended
FFT resolution for MFSK systems thus departing from traditional MFSK processing
to viewing MFSK as a pure spectral analysis problem.

Regards
Adrian G4ZHZ
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>With 32 carriers and 4DQPSK on each of them you would have 4000bps.

This was exactly the number I got fascinated with.
When it came to the actuall implementation, I found out I have to space
carriers a bit wider to reduce crosstalk between them so I came down to
3000 bps. Then, the DQPSK did not work... only DBPSK did (but now I have
an idea why and I will come back to QPSK) so I came down to 1500 bps
- still not too bad.
Timo and Joni from Finland did some tests of this modem and actuall
performance was real bad. I suspect the tuning is a serious issue here.
Their signal levels were S3..5 at the distance of about 15 km.

>Of course the S/N would degrade the performance of such a modulation scheme,
>I think you can win back a lot with coding. But to occupy a whole SSB
>channel for 375bps uncoded data is too inefficient.

The argument to support such inefficiancy is that you can tolerate
interference from other users whose signals come into your band.

>The next problem is the robustness of such a system. I believe if one or
>more frequency bins fade out because of frequency selective fading you are
>in trouble. You would at least have to do some kind of interleaving to
>overcome these effects.

This issue was discussed here last week and we count on our forward
error correction code to restore symbols missed due to selective
fading or narrowbanded interferences.

>The third possibility is the application of broadband signals, OCDM
>(= orthogonal code division multiplex). I've read through an interesting
>article on this topic recently (J. Lindner, "Channel Coding and Modulation
>for Transmission over Multipath Channels", to be published in 
>no. 3 AEUe, May 1995). 
 
Would be very nice if you could say something more on the ideas
expressed in this article.

Yesterday I have made up a band equalization and a ramp-hunting code
as I described it yesterday (no precise ramp measurement yet,
just the coincidence of ramp-up with ramp-down).
I wanted to see how reliable the detection is in the presence of wideband
and narrowbanded noise. I found my ears are just a bit better :-)
but basically the sync. could still be detected when I could hardly hear it.
I should make some more solid signal/noise measurements...

Pawel
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Adrian wrote:

>My opinion is that MFSK is the optimum choice for single HF channel working,
>low-speed data. OFDM is for higher speed working. Both systems need to be
>developed. Perhaps OFDM could be made to degenerate gracefully towards MFSK
>in worsening channel conditions. If we think of OFDM as a number of
>multiplexed MFSK channels, then these channels could be made to drop out
>so that the same transmitter power becomes concentrated across a smaller
>bandwidth thus gaining SNR.

I agree: "both systems need to be developed".

>The point is, MFSK based on FFT is not bad and is very efficient compared
>to the matched correlator approach. It is also potentially upgradable in
>real-time to OFDM. The crucial issues for the MFSK DSP system are: aliasing
>and roundoff noise caused by demodulation to I/Q and decimation, FFT dynamic
>range and tuning control.

My view on the dynamic range of the FFT:

If I do a 256 point FFT, I scale my input data by 1/256 to avoid potential
overflow problem (FFT output gets real messy, when overflows come into
action !). I work with 24-bit numbers (my DSP is DSP56001).

>From the CODEC I am receiving 16 bit samples which are placed in the higher
part of the word (bits 8-23). Thus, by dividing by 256 I do not loose any bit
Infact, I can divide only by 128 if I use the sin(x)^2 window
so I get 1 bit margin.

Now, I do the actuall FFT. I do not know what exactly happens here
but from the simulations I could see that an error is introduced
sometimes on the lowest bit. Thus I almost keep the original
dynamic range, right ?

Well, now you may say that with passband+decimation process you _gain_
extra dynamic range ? This might be true, but I ask a question:
are you sure your passband filters do have enough out-of-band rejection
so that this extra dynamic range it "real" ?

Apropos finding the highest power:

On the FFT output I get 24-bit Is and Qs. I compute power as I*I+Q*Q
and I get a 48-bit number (well, maybe a 49-bit ?).
I then do 48-bit comparisons to find the peak.

By the way a question about HF coherence.
If we do not expect any coherence from HF how can we expect that a piece
of pure wave (picollo symbol) will stay pure (or coherent in other words).
If I assume that the incoming signal's phase is random, such piece of pure
wave should dissolve and its spectrum become wider.
I suspect the phase isn't changing purely randomly and the changes
are "coherent" to a certain degree.
The question is how "coherent" they are, how much can a pure tone
dissolve on HF ?

Pawel
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Pawel:

>If I do a 256 point FFT, I scale my input data by 1/256 to avoid potential
>overflow problem (FFT output gets real messy, when overflows come into
>action !). I work with 24-bit numbers (my DSP is DSP56001).

>From the CODEC I am receiving 16 bit samples which are placed in the higher
>part of the word (bits 8-23). Thus, by dividing by 256 I do not loose any bit
>Infact, I can divide only by 128 if I use the sin(x)^2 window
>so I get 1 bit margin.

Well there is the advantage in using a 24 bit fixed point processor!

Pawel, the way I perform FFTs on the ADSP2101 which is only 16 bits :-(,
is to monitor the exponent of the stage results in block floating point mode,
and to re-scale the block if the bit growth is 2 bits or more, that is, I
start with a 2 bit margin. If bit growth occurs, I change the block exponent
by 2 and re-scale the entire block by this new exponent. In this way I don't
loose the precision of the input data by scaling by 1/N. 

It is possible that the limiting effect of block floating point can cause
problems. If, an incorrect frequency bin has a high magnitude which is close
but just less than the correct frequency bin for the tone being received,
noise in the incorrect bin could just push the block exponent up by
one which will cause the whole block to be renormalized. Also, this noise
will usually have a phase component. Since the real and imaginary data
are in the same block, there is crosstalk between I/Q in terms of the block
exponent. This effect worsens the probablility of error at low SNRs.
Typically I get a character error rate (NB 1 character consists of two symbols) of 1E-02 at an SNR of -9dB in a AWGN channel. This is about 3dB worse than
the equivalent analogue MFSK modem (eg LA1117). Some of this could be due to
aliasing noise though.

Pawel:

>Well, now you may say that with passband+decimation process you _gain_
>extra dynamic range ? This might be true, but I ask a question:
>are you sure your passband filters do have enough out-of-band rejection
>so that this extra dynamic range it "real" ?

There are trade-offs between simplified decimation and heavy demodulation
and decimation but with zero-IF FFT-type spectral analysis instead of
quadrature matched correlators (DFT). I have found in my current MFSK
modem which uses demodulation in phase quadrature to shift the passband
down to 0Hz plus multiple-stage decimation, there is significant aliasing
which needs sorting out. Most of this aliasing is caused by the 2wo image
generated by the demodulation process aliasing. Improved input filtering
would cure this.

The matched correlator approach has just one decimation stage from
7680Hz to 2560Hz. This means there is less filtering so less roundoff
noise and no demodulation which means no 2wo aliasing or further roundoff
noise. In tests, I have not observed any significant noise due to out of
band signals aliasing. This coupled with full floating point arithmetic
for post-accumulation should improve the dynamic range and indeed does
for one correlator tested in isolation. I think therefore, my way of
selecting the peak and synchronisation epoch is wrong rather than the
detector itself. The correlator seems to offer spurious free dynamic range
of an acceptable range (not sure how many dBs but it works OK in the
presence of very much stronger out-of-band signals.)

Pawel:

>By the way a question about HF coherence.
>If we do not expect any coherence from HF how can we expect that a piece
>of pure wave (picollo symbol) will stay pure (or coherent in other words).
>If I assume that the incoming signal's phase is random, such piece of pure
>wave should dissolve and its spectrum become wider.
>I suspect the phase isn't changing purely randomly and the changes
>are "coherent" to a certain degree.
>The question is how "coherent" they are, how much can a pure tone
>dissolve on HF ?

MFSK is non-coherent on HF so I use non-coherent detection. The FFT
or matched quadrature correlator detector both work with complex numbers.
(NB this is another reason why I demodulate the passband to 0Hz in the
complex plane - I use a 16 point complex FFT so all 16 points convey
unique information) Taking the magintude squared just as you do is
phase independant so no problem with the input signal phase shifting around.

I think it is good that we are discussing in more detail the implementation
issues of these digital modems for HF. After all, for an HF channel, things
like dynamic range are very important and we want to develop top-performance
demodulators rather than hoping that the channel coding will make up
for the deficit.

Regards
Adrian
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Adrian:

>Well there is the advantage in using a 24 bit fixed point processor!

I see... your DSP is only 16-bits.

Are you applying any window to your data before the FFT ?
Lack of windowing is a good reason for nearby carriers leaking
into the "good" ones.

Adrian:

>Taking the magintude squared just as you do is
>phase independant so no problem with the input signal phase shifting around.

I was actually wondering, that if you take a pure tone and start shifting
its phase around, the tone will no longer stay pure. If the shift rate
is constant the tone stays pure but changes its frequency (so it may fall
into another picollo demodulator bin). If the shift rate (or the shift itself)
is random the tone will dissolve into a set of frequencies spread around
the original one. If the phase shift is purely random in time, the tone
gets spread all around the band.

My (bad) intention was to trigger a discussion on the coherence on the HF.
People argue that you can not use phase modulation on HF because of lack
of coherence, but if you do not have any coherence then your signals
get spread into an infinite band so even CW doesn't get through :-)

I guess there is still some coherence left on HF :-) and I would like to know
how much of it is left. How can this missed coherence influence non-coherent
systems ? For example is it worth to send picollo with 5 Hz spacing between
tones or would the HF spread such tones over more than 10 Hz so detection
isn't really possible ?

Pawel
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Pawel:

I suspect that the absolute error in tuning your radio will be far greater 
than the offset in a tone during a symbol due to phase errors. By spec on 
the commercial equipment I use, the Radios are supposed to be within +-20Hz 
(older equipment) or +-10Hz(Newer equipment, within last 3-5 years). So if 
one end is +off, the other is -off, a total of +-40Hz(older) or 
+-20Hz(newer) may be observed. I believe the marine standards for GMDSS 
equipment require the modems to work with upto a 40Hz difference between 
ends, and the radios(new) to have less than a 10Hz error.


Also, although you probably know this, but anyway...

Careful of the definition of Coherent detection. You cannot use true PSK on 
HF, but you can use DPSK. i.e. you do not have a reference phase, so PSK is 
not possible. But if you use the previous symbol as a reference, then you 
can use Differential PSK (DPSK).

I suspect some confuse the limit on using coherent detection with not being 
able to use any form of phase modulation. Thus leading to the arguments 
you've heard.

In HF the Phase delay can change over time, typically considered to be only 
a small amount during one or two 100baud symbols. So the phase error 
between successive symbols is small. Of course if a symbol phase is in 
error (phase demodulated wrong) then the next symbol may also be 
demodulated wrong since it is relative to it. So often (usually?) errors 
occur in pairs. Maybe this should be considered in the design of error 
correction and interleaving code for such a modem?

Over longer periods of time phase drift/error on the HF channel becomes 
great (>90degrees after N symbols, N > 10 guess?). So if you locked a phase 
reference at the beginning of the packet and tried PSK demodulation, it 
would probably be well off by the end of the packet.

just my 2cents worth

Paul Russell

From JALOCHA@chopin.ifj.edu.pl Tue Apr 11 11:13:55 1995
Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id LAA00591 for <hfsig@tapr.org>; Tue, 11 Apr 1995 11:13:48 -0500
From: JALOCHA@chopin.ifj.edu.pl
Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cyf-kr.edu.pl (8.6.11/8.6.11) with SMTP id SAA26119 for <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>; Tue, 11 Apr 1995 18:10:38 +0200
Date: Tue, 11 Apr 1995 18:12 GMT+1
Subject: Re: [HFSIG:367] Re: Proposal for a picollo-type modulation
To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>
Message-id: <C0546E9080A07E48@chopin.ifj.edu.pl>
X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org
X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>"

Thanks Paul, very informative answer and it all clear to me:
the phase is random but it drifts slowly thus one can expect
coherence over short periods of time and this is a good reason
for differential phase modulating techniques to work.

Pawel
From kurpiers@zeus.uet.e-technik.th-darmstadt.de Tue Apr 11 11:19:59 1995
Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id LAA00578 for <hfsig@tapr.org>; Tue, 11 Apr 1995 11:11:25 -0500
Received: from zeus (zeus.uet.e-technik.th-darmstadt.de) by rs2.hrz.th-darmstadt.de with SMTP id AA13595
  (5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Tue, 11 Apr 1995 17:23:28 +0200
Received: from hades (hades.uet.e-technik.th-darmstadt.de [130.83.18.78]) by zeus (8.6.9/8.6.9-HRZ) with ESMTP id RAA20770 for <hfsig@tapr.org>; Tue, 11 Apr 1995 17:23:27 +0200
From: Alexander Kurpiers <kurpiers@zeus.uet.e-technik.th-darmstadt.de>
Received: (kurpiers@localhost) by hades (8.6.9/8.6.9-HRZ-Fwd2.0) id RAA13918 for hfsig@tapr.org; Tue, 11 Apr 1995 17:19:16 +0200
Message-Id: <199504111519.RAA13918@hades>
Subject: Re: Proposal for a picollo-type modulation
To: hfsig@tapr.org
Date: Tue, 11 Apr 1995 17:19:16 +0200 (MESZ)
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 4692      


>>With 32 carriers and 4DQPSK on each of them you would have 4000bps.

>This was exactly the number I got fascinated with.
>When it came to the actuall implementation, I found out I have to space
>carriers a bit wider to reduce crosstalk between them so I came down to
>3000 bps. Then, the DQPSK did not work... only DBPSK did (but now I have
>an idea why and I will come back to QPSK) so I came down to 1500 bps
>- still not too bad.
>Timo and Joni from Finland did some tests of this modem and actuall
>performance was real bad. I suspect the tuning is a serious issue here.
>Their signal levels were S3..5 at the distance of about 15 km.

Yes, tunig is the main problem. But I still think that DQPSK can be used.
If you not only use the last received symbol but also the one before that
you can win back a lot compared to coherent demodulation of QPSK. Furthermore
with 2 times differential modulation you get rid of the tunig problem.
On the other hand, you loose about 3dB in S/N for the same BER. This is
of course too much. I recently came accross an interesting paper which
covers a new demodulation scheme (M.K.Simon and D.Divsalar,
"On the Implementation and Performance of Single and Double Differential
Detection Schemes", IEEE Trans. Comm. COM-40, 1992, p. 278-291
and F. Edbauer, "Bit Error Rate of Binary and Quaternary DPSK Signals
with Multiple Differential Feedback Detection", IEEE Trans. Comm. COM-40, 1992,
p. 457-460).



>>The third possibility is the application of broadband signals, OCDM
>>(= orthogonal code division multiplex). I've read through an interesting
>>article on this topic recently (J. Lindner, "Channel Coding and Modulation
>>for Transmission over Multipath Channels", to be published in 
>>no. 3 AEUe, May 1995). 
 
>Would be very nice if you could say something more on the ideas
>expressed in this article.

The basic idea behind the article is the generalization of linear block
modulation with orthogonal functions. If you use single or multicarrier
transmission - that is you use orthogonal sine waves - you have OFDM.
If you use other types of orthogonal functions - you have OCDM.

The author begins with an overview over existing modulation schemes.
The multicarrier approach is quite old and was taken to reduce
the complexity of the receiver. As no equalizition is needed, simple
receiver structures are feasable. It is important to mention that
single carrier schemes have proven to be more effective, but - of course -
require very complex demodulators. I like to mention the new Rhode&Schwarz
HF modem GM857 which uses coded 8PSK on a single carrier to achieve 2k4bps in
an SSB channel. Multicarrier schemes are effective, if you use advanced
coding. The rest of the paper is about the relation of channel coding
and modulation with respect to the multipath channel.

>From previous work it is clear that you can approach the available
channel capacity with OFDM by using a method called "water pouring scheme"
provided you know exactly the channel capacity of each "subchannel". This
can be done using a back channel from the receiver to the transmitter.
I think, this can also be done using ARQ techniques.
 
The reset of the paper is about what you can to do achieve the maximum
channel capacity if you do not have his knowledge. For OFDM the simplest
approach is signal interleaving, you swap the mapping of symbols and
sub channels. Assuming Rayleigh fading channels, the thus created
virtual sub channels are also Rayleigh fading.

If you distribute the symbols over more than one sub channel of the OFDM, you
get OCDM. He shows that the output of the decoder on the receiver side is now
not fading at the expense of intersymbol interference between different signals.

>From a practical point of view this is quite clear, as broadband signals don't
suffer that much from frequency selective fading than narrow band signals do.

The main problem is the need for maximum likelihood reception due to the
intersymbol interference and thus a very complex receiver.



Alexander


-- 
*--------------------------------------------------------------*
|        Alexander F. Kurpiers                                 |
|        Institut fuer Uebertragungstechnik                    |
|        Merckstrasse 25                                       |
|        D-64283 Darmstadt (Germany)                           |
|        Voice: +49-6151-162369                                |
|        Fax  : +49-6151-165545                                |
|        EMail: kurpiers@zeus.uet.e-technik.th-darmstadt.de    |
|        Hamradio: dl8aau@db0kg.#nds.deu.eu                    |
*--------------------------------------------------------------*

From k5yfw@sacdm10.kelly.af.mil Tue Apr 11 12:07:42 1995
Received: from sacdm10.kelly.af.mil (sacdm10.kelly.af.mil [137.242.64.10]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id MAA01092 for <hfsig@tapr.org>; Tue, 11 Apr 1995 12:07:38 -0500
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2)
	id m0ryjNj-0002BUC; Tue, 11 Apr 95 12:05 CDT
Message-Id: <m0ryjNj-0002BUC@sacdm10.kelly.af.mil>
Date: Tue, 11 Apr 95 12:05:39 -0500
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW)
Subject: Two Types of Modems
To: hfsig@tapr.org

For those of us listening in on the SIG who are non-technical types, I
gather that there are two types of modems being discussed here.

One is a very robust modem for worst-case conditions with a low bit
rate but to ensure thurput...less than 100 BPS

The second is a high-speed modem, somewhat robust and desired to
operate under average to poor conditions...about 2400 BPS.

Additionally, I am assuming that development is designed to fit on
multiple platforms to include generic soundcards and external DSP
devices such as the TAPR DSP device.

Someone may want to re-define/state the efforts here so new
subscribers can know our direction.

On a personal note, I believe the greatest interest of this project by
the amateur radio community will be the ability of the average ham to
use a simple computer soundcard to send and receive data on HF at data
rates of up to 2400 BPS over average to poor paths.

Keep up the fine effort.

Best Regards,

qWalt/K5YFW
From FORRERJ@frl.orst.edu Tue Apr 11 15:42:18 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id PAA02055 for <HFSIG@tapr.org>; Tue, 11 Apr 1995 15:42:15 -0500
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id FAA02412 for <HFSIG@tapr.org>; Tue, 11 Apr 1995 05:42:12 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Tue, 11 Apr 95 13:47:59 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 11 Apr 95 13:47:48 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Tue, 11 Apr 1995 13:47:45 PST8PDT
Subject:       PDM-2
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <735F1242AA4@frl.orst.edu>

Alexander,

Thanks for the Simon & Divsalar reference. 

I learned something new today. 

For those interested - DPSK derives signaling states from the difference in 
phase between successive symbols. If only adjacent symbols are considered, 
this is also called PDM-1, however, if one take the difference spread out 
over 'm' several preceeding symbols, this is called PDM-m: PDM-2 when the 
past two symbols are used - this is also called the second deriative of the 
phase difference. The neat thing about this scheme is that doppler shift 
on the signal is cancelled in the detection process! It is stated that PDM-
2, when no frequency offset is present, is some 3 - 4 dB worse than PDM-
1 (i.e. regular DPSK), however, the latter suffers severely in off-
frequency situations when PDM-2 still performs reasonably. Perhaps a good 
method for tuning or symbol synch?

PDM-m can be implemented using either the autocorrelation method (i.e. 
correlating the signal with itself one symbol time delayed) or by the I/Q 
method (shift to baseband, integrate/dump, and autocorrelation). 

I could not make much sense from the Edbauer paper  - perhaps Alexander 
could fill us in. In the same volume (COM-40), April issue, by Casas 
and Leung, there also is a paper on the topic of the effects of fading 
on OFDM - sounds somewhat familiar?

73's

Johan Forrer, KC7WW 








From Glen_Worstell@notes.seagate.com Tue Apr 11 18:09:44 1995
Received: from worldcom.com (worldcom.com [198.64.193.5]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id SAA02840 for <hfsig@tapr.org>; Tue, 11 Apr 1995 18:09:36 -0500
Received: from worldcom-18.worldcom.com (worldcom-18.worldcom.com [198.64.193.9]) by worldcom.com (8.6.11/8.6.9) with SMTP id QAA17139 for <hfsig@tapr.org>; Tue, 11 Apr 1995 16:41:45 -0500
Received: by worldcom-18.worldcom.com (IBM OS/2 SENDMAIL VERSION 1.3.13/3.3)
	  id AA5856; Tue, 11 Apr 95 16:34:39 -0700
Message-Id: <9504112334.AA5856@worldcom-18.worldcom.com>
Received: from worldcom with "Lotus Notes Mail Gateway for SMTP" id  FF4AEC2BB319BDC18625619B00767122; Tue, 11 Apr 95 16:34:39 
To: hfsig <hfsig@tapr.org>
From: Glen Worstell  <Glen_Worstell@notes.seagate.com>
Date: 11 Apr 95 13:15:31 EDT
Subject: computer noise
Mime-Version: 1.0
Content-Type: Text/Plain

Hi,
I am interested in experimenting with some of the ideas presented
in this forum.  To that end I connected my clone 486-33 pc to my
Icom 735 and PK232.  The noise level was about 20 over.
Even using my two meter handheld the noise is stronger than
many signals.

I'd like to purchase a new low noise PC.  The computer droids
know less than nothing about RFI.  Does anyone have any
suggestions or experience with particular brands/models?
Is monitor noise also an issue?

TIA,
Glen, KG0T
From k5yfw@sat.n5lyt.ampr.org Tue Apr 11 18:57:07 1995
Received: from k5yfw.ampr.org (k5yfw.ampr.org [44.76.2.88]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id SAA03045 for <hfsig@tapr.org>; Tue, 11 Apr 1995 18:56:53 -0500
Date: Tue, 11 Apr 95 18:48:08 CST
Message-Id: <2738@k5yfw.ampr.org>
From: k5yfw@k5yfw.ampr.org (Walter D. DuBose - K5YFW)
Reply-To: k5yfw@sat.n5lyt.ampr.org
To: hfsig@tapr.org
Subject: Re: [HFSIG:369] Re: Proposal for a picollo-type modulation
In-Reply-To: Your message of Tue, 11 Apr 1995 11:27:18 -0500
X-Mailer: Bdale's Mailer version PA3AZK.940404 (MSDOS)

Alexander, et al.

In message <199504111519.RAA13918@hades> Alexander writes:
> 
> 
> The author begins with an overview over existing modulation schemes.
> The multicarrier approach is quite old and was taken to reduce
> the complexity of the receiver. As no equalizition is needed, simple
> receiver structures are feasable. It is important to mention that
> single carrier schemes have proven to be more effective, but - of course -
> require very complex demodulators. I like to mention the new Rhode&Schwarz
> HF modem GM857 which uses coded 8PSK on a single carrier to achieve 2k4bps in
> an SSB channel. Multicarrier schemes are effective, if you use advanced
> coding. The rest of the paper is about the relation of channel coding
> and modulation with respect to the multipath channel.

        Could this be something like the single tone modem referenced in
        MIL-STD-188-110a, change notice 2?  One tone that can "do" 4800
        BPS without FEC and 2400 BPS with FEC (Reed-Solomon coding).

        The single tone modem signal sounds just like 3 KHz of noise...
        it fits into a SSB bandpass filter on most U.S. Military
        transceivers.

Walt
From kurpiers@zeus.uet.e-technik.th-darmstadt.de Wed Apr 12 01:34:07 1995
Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id BAA05427 for <hfsig@tapr.org>; Wed, 12 Apr 1995 01:34:03 -0500
Received: from zeus (zeus.uet.e-technik.th-darmstadt.de) by rs2.hrz.th-darmstadt.de with SMTP id AA17505
  (5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Wed, 12 Apr 1995 08:33:17 +0200
Received: from hades (hades.uet.e-technik.th-darmstadt.de [130.83.18.78]) by zeus (8.6.9/8.6.9-HRZ) with ESMTP id IAA17322 for <hfsig@tapr.org>; Wed, 12 Apr 1995 08:33:17 +0200
From: Alexander Kurpiers <kurpiers@zeus.uet.e-technik.th-darmstadt.de>
Received: (kurpiers@localhost) by hades (8.6.9/8.6.9-HRZ-Fwd2.0) id IAA14075 for hfsig@tapr.org; Wed, 12 Apr 1995 08:29:04 +0200
Message-Id: <199504120629.IAA14075@hades>
Subject: Re: Proposal for a picollo-type modulation
To: hfsig@tapr.org
Date: Wed, 12 Apr 1995 08:29:04 +0200 (MESZ)
In-Reply-To: <2738@k5yfw.ampr.org> from "Walter D. DuBose - K5YFW" at Apr 11, 95 07:07:03 pm
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 501       

> 
>         Could this be something like the single tone modem referenced in
>         MIL-STD-188-110a, change notice 2?  One tone that can "do" 4800
>         BPS without FEC and 2400 BPS with FEC (Reed-Solomon coding).
> 
>         The single tone modem signal sounds just like 3 KHz of noise...
>         it fits into a SSB bandpass filter on most U.S. Military
>         transceivers.
> 
> Walt
> 

I just looked in the description of the modem. You are right it's
MIL-STD-188-110a.


Alexander
From nash@camail.ca.nmp.nokia.com Wed Apr 12 03:19:36 1995
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id DAA05664 for <hfsig@tapr.org>; Wed, 12 Apr 1995 03:19:32 -0500
Received: from mgw.nmp.nokia.com (mgw.nmp.nokia.com [131.228.233.85]) by noknic.nokia.com (8.6.9/8.6.9) with SMTP id LAA02187 for <hfsig@tapr.org>; Wed, 12 Apr 1995 11:19:16 +0300
Message-Id: <199504120819.LAA02187@noknic.nokia.com>
Received: from camail.ca.nmp.nokia.com by mgw.nmp.nokia.com with SMTP
	(1.38.193.4/16.2) id AA19129; Wed, 12 Apr 1995 10:15:46 +0200
Received: from bashful.ca.nmp.nokia.com (bashful) by camail with SMTP
	(1.37.109.14/16.2) id AA298134709; Wed, 12 Apr 1995 09:18:29 +0100
Date: Wed, 12 Apr 1995 09:18:29 +0100
From: Adrian Nash <nash@camail.ca.nmp.nokia.com>
To: hfsig@tapr.org
Subject: Re: [HFSIG:366] Re: Proposal for a picollo-type modulation


Pawel:

>Are you applying any window to your data before the FFT ?
>Lack of windowing is a good reason for nearby carriers leaking
>into the "good" ones.

My modem deliberatly uses no window. The sidelobe information is used in two
ways:
	a) by taking the ratio of power in all FFT bins to that in the current
	   peak bin, we get a useful "confidence estimate" which is used for
	   recovering synchronisation but can also be used as a soft decision
	   for a Viterbi Algorithm.

	b) More specifically: I have an auto-tuning algorithm which I have
	   tested using MathCad but currently is not in the modem. This
	   algorithm uses the adjacent frequency bins to the peak to compute
	   with a high degree of confidence and accuracy (so far as the 
	   simulations have shown) the frequency tuning error. This can be
	   used to track drift and Doppler shift as well as perform fine
	   tuning after a user has coarse-tuned the signal. The same algorithm
	   can be made to track phase changes (possibly as quick as those you
	   mention below) by using the FFT phase information. Perhaps this
	   algorithm could be combined with your "triangular" course tuning
	   system to enable the modem to automatically acquire then track
	   the signal. I feel auto-tuning is a very important issue which is
	   essential for amateur high-performance digital modems given the
	   range of amateur HF equipment available.

All the bins are in effect matched filters, one for each tone with no
redundancy.

Pawel:

>I was actually wondering, that if you take a pure tone and start shifting
>its phase around, the tone will no longer stay pure. If the shift rate
>is constant the tone stays pure but changes its frequency (so it may fall
>into another picollo demodulator bin). If the shift rate (or the shift itself)
>is random the tone will dissolve into a set of frequencies spread around
>the original one. If the phase shift is purely random in time, the tone
>gets spread all around the band.

This reminds me of some work I did investigating the effects of fast fading
on MFSK. MFSK is a bit prone to fast fades (eg fade rate >1Hz.) The effect
is that the tone's energy is spread across a band with a normal (Gaussian)
distribution due to the violent (eg 180degs) phase changes that occur with
this type of fade. The width of the modulation depends upon the fade rate.
In the case of orthogonal MFSK, the effect of the 180 degree phase change is
to create a strong component in the adjacent frequency bins which when
integrated can produce an erroneous selection.

This is where perhaps I need to look at the demodulation of MFSK as a pure
spectral analysis problem rather than the slightly "digital for analogue"
way in which the current modem works. Finer FFT resolution with windowing
as you suggest would reduce cross-talk.

Pawel:

>I guess there is still some coherence left on HF :-) and I would like to know
>how much of it is left. How can this missed coherence influence non-coherent
>systems ? For example is it worth to send picollo with 5 Hz spacing between
>tones or would the HF spread such tones over more than 10 Hz so detection
>isn't really possible ?

Doppler shifts of 5Hz have been observed on HF circuits therefore I assume that
this narrow spacing would cause problems. Also, the narrower the separation
the more prone the MFSK system becomes to selective fading. If the frequency
separation of two tones is made equal to the reciprocal of the differential
path delay, one tone will be at a maximum when the other is at a minimum.
Therefore, a typical MFSK signal with a bandwidth between 180Hz and 360Hz
(single channel) affords some protection against multipath selective fading.
Infact, this is apparently where MFSK scores highly over straight DPSK - it
is much better in a selective fading channel. However, I think this is not
the issue it was with the advent of sophisticated channel coding techniques
available.

Regards
Adrian

From JALOCHA@chopin.ifj.edu.pl Wed Apr 12 04:35:20 1995
Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id EAA05798 for <hfsig@tapr.org>; Wed, 12 Apr 1995 04:35:10 -0500
From: JALOCHA@chopin.ifj.edu.pl
Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cyf-kr.edu.pl (8.6.11/8.6.11) with SMTP id LAA00826 for <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>; Wed, 12 Apr 1995 11:32:45 +0200
Date: Wed, 12 Apr 1995 11:34 GMT+1
Subject: Re: [HFSIG:367] Re: Proposal for a picollo-type modulation
To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>
Message-id: <51E7C25B00A092DA@chopin.ifj.edu.pl>
X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org
X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>"

Paul:

>In HF the Phase delay can change over time, typically considered to be only 
>a small amount during one or two 100baud symbols. So the phase error 
>between successive symbols is small.

A related question: what about the group delay variation across frequency ?
I mean when I am receiving a multi-carrier signal and I find the symbol timing
for one carrier can I use same timing for other carriers ?
Or should I adjust the symbol timing for every carrier separately ?

By the way, does an average SSB filter introduces a significant
group delay variation ? If we use 100 bps per carrier then variation
of +/- few ms is very significant.

Pawel
From paulr@hagar.udc.neweast.ca Wed Apr 12 07:14:11 1995
Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id HAA06140 for <hfsig@tapr.org>; Wed, 12 Apr 1995 07:14:07 -0500
Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35)
	id AA14062; Wed, 12 Apr 95 12:14:05 GMT
Received: from cc:Mail by ccsmtp.udc.neweast.ca
	id AA797705048; Wed, 12 Apr 95 09:41:43 nst
Date: Wed, 12 Apr 95 09:41:43 nst
From: "Paul Russell" <paulr@hagar.udc.neweast.ca>
Encoding: 36 Text
Message-Id: <9503127977.AA797705048@ccsmtp.udc.neweast.ca>
To: hfsig@tapr.org
Subject: Re: [HFSIG:372] computer noise

I have found files (inc FAQs) that mention cures for RFI at:
     mailing list:
          send message containing word "index" in body to info@arrl.org

try also: 
        ftp://ftp.cs.buffalo.edu/pub/ham-radio/
        http://dingus.n5lyt.datapoint.com:80/tapr/
        http://hamster.business.uwo.ca/
        

If anyone out there can tell me where to get QEX, QST and the other publications
often referred to on this list I would appreciate it.

Paul Russell


______________________________ Reply Separator _________________________________
Subject: [HFSIG:372] computer noise
Author:  hfsig@tapr.org at nwtsmtp
Date:    4/11/95 8:42 PM


Hi,
I am interested in experimenting with some of the ideas presented 
in this forum.  To that end I connected my clone 486-33 pc to my 
Icom 735 and PK232.  The noise level was about 20 over.
Even using my two meter handheld the noise is stronger than 
many signals.

I'd like to purchase a new low noise PC.  The computer droids 
know less than nothing about RFI.  Does anyone have any 
suggestions or experience with particular brands/models?
Is monitor noise also an issue?

TIA,
Glen, KG0T

From paulr@hagar.udc.neweast.ca Wed Apr 12 07:41:19 1995
Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id HAA06284 for <hfsig@tapr.org>; Wed, 12 Apr 1995 07:41:08 -0500
Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35)
	id AA14102; Wed, 12 Apr 95 12:41:05 GMT
Received: from cc:Mail by ccsmtp.udc.neweast.ca
	id AA797706668; Wed, 12 Apr 95 10:10:16 nst
Date: Wed, 12 Apr 95 10:10:16 nst
From: "Paul Russell" <paulr@hagar.udc.neweast.ca>
Encoding: 59 Text
Message-Id: <9503127977.AA797706668@ccsmtp.udc.neweast.ca>
To: hfsig@tapr.org
Subject: Re: [HFSIG:376] Re: Proposal for a picollo-type modulation

>Paul wrote:
>>In HF the Phase delay can change over time, typically considered to be 
>>only a small amount during one or two 100baud symbols. So the phase error 
>>between successive symbols is small.
>
>Pawel wrote:
>A related question: what about the group delay variation across frequency ?
>I mean when I am receiving a multi-carrier signal and I find the symbol timing 
>for one carrier can I use same timing for other carriers ?
>Or should I adjust the symbol timing for every carrier separately ?
>
>By the way, does an average SSB filter introduces a significant 
>group delay variation ? If we use 100 bps per carrier then 
>variation of +/- few ms is very significant.

Hadn't thought about it this way, I hope its not significant. I've been allowing
the windowing effect to cure/hide any variance in delay between frequencies. 
i.e. the symbols were pinched near their edges, so several samples of variance 
would have little effect at the edges. But if I'm going to be shaping over 
several symbols as you have suggested, I don't know anymore?!

Definitely the phase of each tone in a symbol (M-ary DPSK) is compared to the 
same tone in the preceding symbol, not a reference tone, as there may be 
different phase delays per tone (here we are comparing the phase of a single 
cycle of a sine wave, not the time delay of the whole symbol's tone). But if the
delay differences per tone are such that the difference in propagation of each 
tone affects symbol timing - our modems are going to be significantly more 
complex - basically a bunch of independent DPSK or FSK modems running totally 
independently, different FFT's, DPLL's, etc per tone.

I have seen no references in anyone's designs for this yet, including what I 
have read about Clover and MIL-STD-188, etc. If the variance in propagation 
delays would affect DPSK, they would also affect FSK. It may not be optimal, but
since no-one else has found it a problem, I'm going to ignore it till I find it 
a problem. "Ignorance is bliss" - you are trying to steal my "bliss" <g>.

But then again, alot of these designs use correlators, not FFT's. The 
correlation on each tone "may" track independently from the next and thus 
compensate for this. Whereas an FFT samples all the Tones from the same 
reference time-mark. Hum...?

        The following are only guesses, Someone please provide factual info:

Maybe someone more knowledgable will step in, but I toss in some idle comments 
here. Speed through a medium of electromagnetic signals is related to the speed 
of light. All of our signals when modulated to RF are relatively the same 
frequency - whats a 1KHz tone difference when modulated onto 5MHz - 5.000 vs 
5.001 - little. So I would expect most of the group phase variance to occur 
while the signal is in the audio spectrum, before and after modulation (or 
during the modulation).  I'll hazard a guess that the variance in the signals 
propagation no more than a fraction of a cycles of the audio tone (when in RF 
state). If you have the group delay plots from any of your filter designs handy,
check them and see what difference is for audio level frequencies. Multiple by 
about 10 for all the stages it passes through - will it affect bit timing? - 
i.e. more than about ~8 audio samples at 8KHz sampling (64 samples/symbol, ~1/8 
symbol, 1 millisecond)? Different shaping/windowing functions will provide 
more/less grace around the edges of a symbols.

Paul Russell

From paulr@hagar.udc.neweast.ca Wed Apr 12 09:47:20 1995
Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id JAA06671 for <hfsig@tapr.org>; Wed, 12 Apr 1995 09:47:12 -0500
Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35)
	id AA15907; Wed, 12 Apr 95 14:47:05 GMT
Received: from cc:Mail by ccsmtp.udc.neweast.ca
	id AA797714228; Wed, 12 Apr 95 12:16:40 nst
Date: Wed, 12 Apr 95 12:16:40 nst
From: "Paul Russell" <paulr@hagar.udc.neweast.ca>
Encoding: 36 Text
Message-Id: <9503127977.AA797714228@ccsmtp.udc.neweast.ca>
To: hfsig@tapr.org
Subject: Re: [HFSIG:372] computer noise

I have found files (inc FAQs) that mention cures for RFI at:
     mailing list:
          send message containing word "index" in body to info@arrl.org

try also: 
        ftp://ftp.cs.buffalo.edu/pub/ham-radio/
        http://dingus.n5lyt.datapoint.com:80/tapr/
        http://hamster.business.uwo.ca/
        

If anyone out there can tell me where to get QEX, QST and the other publications
often referred to on this list I would appreciate it.

Paul Russell


______________________________ Reply Separator _________________________________
Subject: [HFSIG:372] computer noise
Author:  hfsig@tapr.org at nwtsmtp
Date:    4/11/95 8:42 PM


Hi,
I am interested in experimenting with some of the ideas presented 
in this forum.  To that end I connected my clone 486-33 pc to my 
Icom 735 and PK232.  The noise level was about 20 over.
Even using my two meter handheld the noise is stronger than 
many signals.

I'd like to purchase a new low noise PC.  The computer droids 
know less than nothing about RFI.  Does anyone have any 
suggestions or experience with particular brands/models?
Is monitor noise also an issue?

TIA,
Glen, KG0T

From FORRERJ@frl.orst.edu Wed Apr 12 10:55:38 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id KAA07084 for <HFSIG@tapr.org>; Wed, 12 Apr 1995 10:55:34 -0500
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id AAA07969 for <HFSIG@tapr.org>; Wed, 12 Apr 1995 00:55:29 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Wed, 12 Apr 95 9:01:18 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 12 Apr 95 9:01:16 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Wed, 12 Apr 1995 09:01:16 PST8PDT
Subject:       ITU/TIES
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <7492B2E7EAF@frl.orst.edu>

Hi All,

I need some help finding a CCIR document on ITU/TIES. 

The ITU server is on the WWW at: http:\\www.itu.ch 
though the amount of literature are overwhelming. 
Does anyone know where to look/obtain a specific issue of the
CCIR specifications ?

I know Tom McDermott has told us how to do this, though have
not succeeded myself. I have not been able to contact Tom via 
e-mail lately. Anyone know his whereabouts?

Any help/pointers would be much appreciated.

73's

--Johan, KC7WW
From rsmith@internetMCI.COM Wed Apr 12 11:31:42 1995
Received: from mailsrv1.pcy.mci.net ([204.70.138.5]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id LAA07228 for <hfsig@tapr.org>; Wed, 12 Apr 1995 11:31:34 -0500
Received: from [204.71.164.23] (dialup23.Washington.mci.net)
 by MAILSRV1.PCY.MCI.NET (PMDF V4.3-12 #10044)
 id <01HP92FB69CW95MS2O@MAILSRV1.PCY.MCI.NET>; Wed,
 12 Apr 1995 12:30:59 +0000 (GMT)
Date: Wed, 12 Apr 1995 12:31:21 -0500
From: Bob Smith <rsmith@internetMCI.COM>
Subject: computer noise
To: "hfsig@tapr.org" <hfsig@tapr.org>
Message-id: <01HP92FBPO7695MS2O@MAILSRV1.PCY.MCI.NET>
X-Mailer: E-Mail Connection vb.2.5.02
Content-transfer-encoding: 7BIT

-- [ From: Bob Smith * EMC.Ver #b.2.5.02 ] --

You may try good grounding techniques Glen.  Strap everything with the
braid from RG/8 then to your station ground.  This cleared things up very
well for me.


Date: Tuesday, 11-Apr-95 06:10 PM

From: Glen Worstell            \ Internet:    
(glen_worstell@notes.seagate.com)
To:   hfsig@tapr.org           \ Internet:    (hfsig@tapr.org)
You may try good grounding techniques Tia.  Strap everything with the braid
from RG/8 then to your station ground.  This cleared things up very well
for me.

Subject: [HFSIG:372] computer noise

Hi,
I am interested in experimenting with some of the ideas presented in this
forum.  To that end I connected my clone 486-33 pc to my Icom 735 and
PK232.  The noise level was about 20 over. Even using my two meter handheld
the noise is stronger than many signals.

I'd like to purchase a new low noise PC.  The computer droids know less
than nothing about RFI.  Does anyone have any suggestions or experience
with particular brands/models? Is monitor noise also an issue?

TIA,
Glen, KG0T
------- FORWARD, End of original message -------


From mcdermot@eagle.aud.alcatel.com Wed Apr 12 16:19:16 1995
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id QAA09044 for <hfsig@tapr.org>; Wed, 12 Apr 1995 16:19:13 -0500
Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1)
	id AA16347; Wed, 12 Apr 95 16:19:11 CDT
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1)
	id AA04448; Wed, 12 Apr 95 16:19:10 CDT
Date: Wed, 12 Apr 95 16:19:10 CDT
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott)
Message-Id: <9504122119.AA04448@eagle.aud.alcatel.com>
To: hfsig@tapr.org
Subject: Re: [HFSIG:380] ITU/TIES

> From hfsig@tapr.org Wed Apr 12 11:14:35 1995
> Reply-To: hfsig@tapr.org
> Originator: hfsig@tapr.org
> Sender: hfsig@tapr.org
> To: hfsig@tapr.org
> Subject: [HFSIG:380] ITU/TIES
> X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas
> X-Comment: Tucson Amateur Packet Radio  HF Special Interest Group
> Content-Length: 489
> X-Lines: 18
>
> Hi All,
>
> I need some help finding a CCIR document on ITU/TIES.
>
> The ITU server is on the WWW at: http:\\www.itu.ch
> though the amount of literature are overwhelming.
> Does anyone know where to look/obtain a specific issue of the
> CCIR specifications ?
>
> I know Tom McDermott has told us how to do this, though have
> not succeeded myself. I have not been able to contact Tom via
> e-mail lately. Anyone know his whereabouts?
>
> Any help/pointers would be much appreciated.
>
> 73's
>
> --Johan, KC7WW
>

	OK.  Here's what I did.

1. telnet gopher.itu.ch 2000
	This connects you to the gopher at CCITT.
2. Theres a list of choices.  Use J to go down, K to go up (UNIX standard)
	or you can type in the number you want, and it will go there
	directly.
3. I selected 3 - ITU Standards, Publications, Databases, Meetings, Press...
4. I selected 2 - ITU Radiocommunications Standards
5. From the next menu, I selected 23 - Index of ITU-R Recommendations by
	numerical order.
6. You can then download the raw ASCII or a WORD2.0 version.

Other paths through the gopher...

3. Select 1 - ITU Telecommunications Standards.
4. Select 13 - M series Recommendations - you can look through the list
	of recommendation titles on line, or select the option to
	download a postscript version of the list.

Another path...

Select 9 - Catalog of ITU-R Recommendations
	this will show how to search by keyword(s) through the recommendation,
A search on 'Propagation' turned up a number of cited references.

there are many other search engines available, and some of the text of the
recommendations, etc. are available on-line by Postscript, ASCII, or
WORD2.0 download.


							- Tom, N5EG


2. Select 3. from the main menu - ITU Telecommuncations

------------------------------------------------+-----------------------------
 Tom McDermott					| "All opinions expressed
 Alcatel Network Systems, Inc.			| are my own, and do not
 mcdermot@aud.alcatel.com			| represent those of Alcatel
   [ ICC'96 Technical Program Secretary ]	| Network Systems, Inc."
   [   June 23-27, 1996, Dallas, Tx.    ]	|
------------------------------------------------+-----------------------------
From mcdermot@eagle.aud.alcatel.com Wed Apr 12 16:54:01 1995
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id QAA09205 for <hfsig@tapr.org>; Wed, 12 Apr 1995 16:53:57 -0500
Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1)
	id AA17491; Wed, 12 Apr 95 16:53:55 CDT
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1)
	id AA04956; Wed, 12 Apr 95 16:53:53 CDT
Date: Wed, 12 Apr 95 16:53:53 CDT
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott)
Message-Id: <9504122153.AA04956@eagle.aud.alcatel.com>
To: hfsig@tapr.org
Subject: Gopher screen shots (long)



	Here's some screen shots on the way to finding the
ITU-R M-series recommendations.....
-------------------------------------------------------------------------------




		ITU Telecom Information Exchange Services (TIES)

		  International Telecommunication Union (ITU)

 -->  1.  About ITU, TIES, ITUDOC, Copyright, What's new.../
      2.  Search menu titles in ITU Gopher <?>
      3.  ITU Standards, Publications, Databases, Meetings, Press.../
      4.  ITU Telecommunication Standardization Sector/
      5.  ITU Radiocommunication Sector/
      6.  ITU Telecommunication Development Sector/
      7.  ITU General Secretariat/
      8.  ITU Office of the Secretary-General/
      9.  TELECOM Exhibitions and Forums/
      10. Telecommunications-related topics/
      11. United Nations & international organizations/
      12. Permanent Missions based in Geneva/
      13. Other information services/
















Press ? Help, q Quit, D Download                                    Page: 1/1

		ITU Telecom Information Exchange Services (TIES)

	   ITU Standards, Publications, Databases, Meetings, Press...

 -->  1.  ITU Telecommunication Standards (ITU-T Recommendations)/
      2.  ITU Radiocommunication Standards (ITU-R Recommendations)/
      3.  ITU Publications (July 1994 Catalogue)
      4.  ITU Schedule of Meetings/
      5.  ITU Press Releases/
      6.  ITU Global Telecom Directory/
      7.  ITU Country Codes database/
      8.  Catalogue of ITU-T Recommendations/
      9.  Catalogue of ITU-R Recommendations/
      10. Catalogue of ITU-R Questions/
      11. Database of ITU Software for Frequency Management/
      12. ITU/BDT Databases/
      13. ITU Constitution, Convention, .../
      14. ITU Telecommunication Terminology Database (TERMITE)/















Press ? Help, q Quit, u up a menu, D Download                       Page: 1/1


		ITU Telecom Information Exchange Services (TIES)

	    ITU Radiocommunication Standards (ITU-R Recommendations)

 -->  1.  Series ITU-R BO Recommendations    [Broadcasting satellite
 service../
      2.  Series ITU-R BR Recommendations    [Sound and television
      recording../
      3.  Series ITU-R BS Recommendations    [Broadcasting service (sound)]/
      4.  Series ITU-R BT Recommendations    [Broadcasting service
      (televisi../
      5.  Series ITU-R F Recommendations      [Fixed service]/
      6.  Series ITU-R IS Recommendations     [Inter-service sharing and
      com../
      7.  Series ITU-R M Recommendations      [Mobile, radiodetermination,
      a../
      8.  Series ITU-R PI Recommendations     [Propagation in ionized media]/
      9.  Series ITU-R PN Recommendations    [Propagation in non-ionized
      med../
      10. Series ITU-R RA Recommendations    [Radioastronomy]/
      11. Series ITU-R S Recommendations      [Fixed satellite service]/
      12. Series ITU-R SA Recommendations    [Space applications]/
      13. Series ITU-R SF Recommendations    [Frequency sharing between the
      ../
      14. Series ITU-R SM Recommendations   [Spectrum management techniques]/
      15. Series ITU-R SNG Recommendations [Satellite news gathering]/
      16. Series ITU-R TF Recommendations    [Time signals and frequency
      sta../
      17. Series ITU-R V Recommendations     [Vocabulary and related
      subject../
      18. List of ITU-R Recommendations available electronically to TIES
      reg../
      19. Table of ITU-R Recommendations (1994), Resolutions & Questions
      ava../
      20. HOW-TO-ORDER ITU-R Recommendations/
      21. Distribution of Recommendations in force as from 2 September 1994/
      22. Index of ITU-R Recommendations SERIES/
      23. Index of ITU-R Recommendations by numerical order/
      24. 1994 Volumes of ITU-R Recommendations/





Press ? Help, q Quit, u up a menu, D Download                       Page: 1/1


		ITU Telecom Information Exchange Services (TIES)

		     Index of ITU-R Recommendations SERIES

 -->  1.  [ASCII Lang: EFS Bytes: 3492  Updated: 94-01-06  ITU-6701]
      2.  [WINWORD2.0 Lang: EFS Bytes: 7869  Updated: 94-09-06  ITU-669..
      <Bin>



























Press ? Help, q Quit, u up a menu, D Download                       Page: 1/1




		ITU Telecom Information Exchange Services (TIES)

		List of ITU-R M-Series Recommendations in force

 -->  1.  [ASCII Lang: EFS Bytes: 62628  Updated: 94-11-16  ITU-6712]
      2.  [WINWORD2.0 Lang: EFS Bytes: 54375  Updated: 94-11-15  ITU-66..
      <Bin>



























Press ? Help, q Quit, u up a menu, D Download                       Page: 1/1





------------------------------------------------+-----------------------------
 Tom McDermott					| "All opinions expressed
 Alcatel Network Systems, Inc.			| are my own, and do not
 mcdermot@aud.alcatel.com			| represent those of Alcatel
   [ ICC'96 Technical Program Secretary ]	| Network Systems, Inc."
   [   June 23-27, 1996, Dallas, Tx.    ]	|
------------------------------------------------+-----------------------------
From erik@ve7mdl.ampr.org Wed Apr 12 21:07:14 1995
Received: from whistler.sfu.ca (whistler.sfu.ca [142.58.103.1]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id VAA10690 for <hfsig@tapr.org>; Wed, 12 Apr 1995 21:07:09 -0500
From: erik@ve7mdl.ampr.org
Received: from hamgate.ve7sfu.ampr.org (hamgate.comm.sfu.ca [142.58.173.14]) by whistler.sfu.ca with SMTP (8.6.11/SFU-2.6H)
  id TAA02569 for <hfsig@tapr.org> (from erik@ve7mdl.ampr.org); Wed, 12 Apr 1995 19:07:08 -0700
Received: from ve7mdl.ampr.org by hamgate.ve7sfu.ampr.org (JNOS1.10i) with SMTP
	id AA3180 ; Wed, 12 Apr 95 17:50:47 
Date: Wed, 12 Apr 95 19:07:06 
Message-Id: <12157@ve7mdl.ampr.org>
To: hfsig@tapr.org
Subject: Re: [HFSIG:380] ITU/TIES
In-Reply-To: your message of Wed Apr 12 10:58:05 1995
             <7492B2E7EAF@frl.orst.edu>

CCIR is now called ITU-R.  You can get a list of the documents via email.
I think the email address is 'itudoc@itu.ch'.  Try putting 'info' or
'index' in the first line of the message.

If it does not work, try sending me a message at 'erik@mda.ca' and I will
dig out the detailed instructions at work.

73 de VE7MDL                  ....Erik.
From mcdermot@eagle.aud.alcatel.com Thu Apr 13 09:02:45 1995
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id JAA14023 for <hfsig@tapr.org>; Thu, 13 Apr 1995 09:02:42 -0500
Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1)
	id AA08715; Thu, 13 Apr 95 09:02:41 CDT
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1)
	id AA05630; Thu, 13 Apr 95 09:02:40 CDT
Date: Thu, 13 Apr 95 09:02:40 CDT
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott)
Message-Id: <9504131402.AA05630@eagle.aud.alcatel.com>
To: hfsig@tapr.org
Subject: Optimal OFDM pulses


	I came across an interesting reference:

"Optimal Finite Duration Pulses for OFDM", A. Vahlin & N. Holte,
Globecom '94, pg. 258-262, paper #7.7

It discusses the generation of a pulse that is finite in duration, yet has
good spectral properties for OFDM systems.  Three examples listed look
pretty good.  Unfortunately, there is no closed-form solution to the
minimization effort.  It requires solving 20 simultaneous equations looking
for optimal coefficients of a spheroidal wave function I've never heard of
(and
is not documented in the paper).  The author provides the coefficients for
2T, 3T, and 4T length pulses (where h(t) is zero outside the interval), and
the very good spectrum for the pulses.  However, without the PSWF,
I cannot numerically regenerate h(t).  The article has some references to
the BSTJ, back about 1960 when this wave function was defined.

There are some other references in the article pointing to more recent IEEE
Transactions on Communications addressing the subject, but I don't have the
article with me.  If there is any interest, I'll post the references.


							- Tom, N5EG


------------------------------------------------+-----------------------------
 Tom McDermott					| "All opinions expressed
 Alcatel Network Systems, Inc.			| are my own, and do not
 mcdermot@aud.alcatel.com			| represent those of Alcatel
   [ ICC'96 Technical Program Secretary ]	| Network Systems, Inc."
   [   June 23-27, 1996, Dallas, Tx.    ]	|
------------------------------------------------+-----------------------------
From mcdermot@eagle.aud.alcatel.com Thu Apr 13 09:23:50 1995
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id JAA14304 for <hfsig@tapr.org>; Thu, 13 Apr 1995 09:23:47 -0500
Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1)
	id AA09414; Thu, 13 Apr 95 09:23:45 CDT
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1)
	id AA05641; Thu, 13 Apr 95 09:23:44 CDT
Date: Thu, 13 Apr 95 09:23:44 CDT
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott)
Message-Id: <9504131423.AA05641@eagle.aud.alcatel.com>
To: hfsig@tapr.org
Subject: Re: [HFSIG:378] Re: Proposal for a picollo-type modulation

Paul Russell writes:


> Definitely the phase of each tone in a symbol (M-ary DPSK) is compared to
the
> same tone in the preceding symbol, not a reference tone, as there may be
> different phase delays per tone (here we are comparing the phase of a single
> cycle of a sine wave, not the time delay of the whole symbol's tone). But if
the
> delay differences per tone are such that the difference in propagation of
each
> tone affects symbol timing - our modems are going to be significantly more
> complex - basically a bunch of independent DPSK or FSK modems running
totally
> independently, different FFT's, DPLL's, etc per tone.

	Most of the literature on HF channel simulation has shown/assumed
that the channel is non-dispersive out to 4 khz bandwidth.  This means that
the propagation velocity is not frequency-dependent.  This assumption
breaks down at greater bandwidth.  Thus, symbol-timing can generally be
derived for a group of carriers.  However, the symbol duration must be long
enough that multi-path distortion does not move an individual pulse or
channel very much with respect to the recovered symbol timing.  This
timing is usually in the range 50-200 baud on many HF circuits.

							- Tom, N5EG


------------------------------------------------+-----------------------------
 Tom McDermott					| "All opinions expressed
 Alcatel Network Systems, Inc.			| are my own, and do not
 mcdermot@aud.alcatel.com			| represent those of Alcatel
   [ ICC'96 Technical Program Secretary ]	| Network Systems, Inc."
   [   June 23-27, 1996, Dallas, Tx.    ]	|
------------------------------------------------+-----------------------------
From FORRERJ@frl.orst.edu Thu Apr 13 12:37:26 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id MAA16022 for <hfsig@tapr.org>; Thu, 13 Apr 1995 12:37:23 -0500
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id CAA16438 for <hfsig@tapr.org>; Thu, 13 Apr 1995 02:37:14 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Thu, 13 Apr 95 10:43:06 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Thu, 13 Apr 95 10:42:56 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Thu, 13 Apr 1995 10:42:53 PST8PDT
Subject:       Re: [HFSIG:382] Re: ITU/TIES
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <762DDAD64A6@frl.orst.edu>


Greetings,

Thanks for all the help with ITU/TIES. 

73's

Johan, KC7WW
From tomob@netcom.com Fri Apr 14 15:00:09 1995
Received: from netcom15.netcom.com (netcom15.netcom.com [192.100.81.128]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id PAA22411 for <hfsig@tapr.org>; Fri, 14 Apr 1995 15:00:06 -0500
Received: by netcom15.netcom.com (8.6.12/Netcom)
	id MAA02865; Fri, 14 Apr 1995 12:59:56 -0700
Date: Fri, 14 Apr 1995 12:59:55 -0700 (PDT)
From: "Thomas E. O'Boyle" <tomob@netcom.com>
Subject: DSP Developer Needed
To: HFSIG <hfsig@tapr.org>
Message-ID: <Pine.3.89.9504141237.A2107-0100000@netcom15>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


Greetings to members of the HFSIG!
 
We are a small company (six people) located in Chicago that is working
to finish development of a commercial HF data product. We have a
targeted niche application in mind, and have received one patent and another
is pending. Our design is based on a TMS320 series DSP. We have modeled
the specific modulation approach that we intend to use against a simulation
of multi-path and Gaussian noise and believe that we are on the right track.
We are looking for an additional full-time engineer for this project.
Qualifications are microcontroller and DSP experience and a love of radio.
This might be the chance to enhance your career while working on a project
related to your hobby. Competitive pay and benefits; informal, hardworking,
entrepreneurial environment. For more info, fax a letter and resume to
(312) 463-9738, or respond by private E-mail.
 
Thanks to Johan Forrer for allowing us to post this message.
 
73 de Tom, N9GUN. 
                                             tomob@netcom.com

From tomob@netcom.com Fri Apr 14 15:01:12 1995
Received: from netcom15.netcom.com (netcom15.netcom.com [192.100.81.128]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id PAA22424 for <hfsig@tapr.org>; Fri, 14 Apr 1995 15:01:09 -0500
Received: by netcom15.netcom.com (8.6.12/Netcom)
	id MAA02413; Fri, 14 Apr 1995 12:55:12 -0700
Date: Fri, 14 Apr 1995 12:55:11 -0700 (PDT)
From: "Thomas E. O'Boyle" <tomob@netcom.com>
Subject: DSP Developer Needed
To: HFSIG <hfsig@tapr.org>
Message-ID: <Pine.3.89.9504141215.A2107-0100000@netcom15>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

**

                                             tomob@netcom.com

From karn@qualcomm.com Fri Apr 14 15:53:54 1995
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id PAA22759 for <hfsig@tapr.org>; Fri, 14 Apr 1995 15:53:50 -0500
Received: (karn@localhost) by servo.qualcomm.com (8.6.10/QC-BSD-2.5) id NAA21549; Fri, 14 Apr 1995 13:56:45 -0700
Date: Fri, 14 Apr 1995 13:56:45 -0700
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199504142056.NAA21549@servo.qualcomm.com>
To: hfsig@tapr.org, tcp-group@ucsd.edu
Subject: my web page

I've finally gotten around to creating a web page. There's not a lot of
technical content yet, but I intend to update it with pointers to my
various papers and software projects.

The URL is

http://www.qualcomm.com/people/pkarn

--Phil
From jra@ag9v.ampr.org Sat Apr 15 15:58:40 1995
Received: from udcps3.cps.udayton.edu (udcps3.cps.udayton.edu [131.238.17.3]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id PAA29193; Sat, 15 Apr 1995 15:58:36 -0500
Received: by udcps3.cps.udayton.edu (Smail3.1.26.7 #8)
	id m0s0EzP-0002XTC; Sat, 15 Apr 95 21:02 GMT
Received: (from jra@localhost) by ag9v.ampr.org (8.6.9/8.6.9) id OAA05660; Sat, 15 Apr 1995 14:00:10 -0400
Message-Id: <199504151800.OAA05660@ag9v.ampr.org>
Subject: PACK&\
To: aprssig@tapr.org, hfsig@tapr.org, dsp93sig@tapr.org
Date: Sat, 15 Apr 1995 14:00:09 -0400 (EDT)
From: jra@ag9v.ampr.org
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 1777      

Attending the 1995 Dayton Hamvention?  Time's running out to register
for PACK*BASH!

What?
        A new event for the digitally-inclined ham, featuring:
        *  Buffet dinner (with cash bar)
        *  Dewayne Hendricks, WA8DZP, speaking on PCS, SS, FCC, and
           other acronyms
        *  Bob Bruninga, WB4APR, speaking on the Future of APRS
        *  Prize raffle
        *  TAPR special interest group meetings
        *  "Birds of a Feather" gatherings

When?
        Friday evening, April 28, 1995
        Dinner starts at 7:00 pm
        Speaker at 7:45
        Meetings to begin after the speaker


Where?
        TJ's Restaurant
        2462 Dryden Road, Dayton
        (Dryden Road exit, I75 -- across from the Holiday Inn)

How?
        Dinner requires advance registration and payment BY APRIL 24th, 1995.
        Seating for dinner only is limited, so register early!  The cost is
        $16.00 per person, tax and tip included.

        All amateurs are welcomed to attend, enjoy the speaker, and
        particpate in the meetings, although only those purcashing a dinner 
        can eat.

        To register, contact:
	PACK*BASH
        c/o TAPR
        8987-309 E. Tanque Verde Road #337
        Tucson, AZ   85749-9399

        Phone: (817) 383-0000
        Fax: (817) 566-2544
        Internet: TAPR@TAPR.ORG

        Visa/Mastercard Accepted

Who?
        PACK*BASH is co-sponsored by TAPR -- Tucson Amateur Packet Radio,
        the national leader in digital communication -- and the Miami
        Valley FM Association, Dayton's packet radio club.

For further information, contact TAPR, or email packbash@ag9v.ampr.org or
BASH@N8ACV.#DAY.OH.USA.NOAM
-- 
John Ackermann   AG9V
Internet:  jra@ag9v.ampr.org
Packet:    AG9V@N8ACV.#DAY.OH.USA
From FORRERJ@frl.orst.edu Tue Apr 18 13:16:09 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id NAA16800 for <HFSIG@tapr.org>; Tue, 18 Apr 1995 13:16:05 -0500
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id DAA14982 for <HFSIG@tapr.org>; Tue, 18 Apr 1995 03:15:38 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Tue, 18 Apr 95 11:21:56 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 18 Apr 95 11:21:40 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Tue, 18 Apr 1995 11:21:35 PST8PDT
Subject:       HFSIG activities
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <56CCA54471@frl.orst.edu>

Hi All,

A brief update: There are considerable amount of activity going on behind 
the scenes - this mostly has to with DSP specific stuff. Adrian, G4ZHZ, 
and Pawel, SP4VRC, both are making good progress.

One reality that we have to deal with is that different DSP platforms are 
being used - understandable for good reasons. I am trying to stay involved 
by cross-porting where possible. For this reason, I have been working at 
porting some of the Finnish group's (Alef Null) code. This code runs on 
a Motorola 56K-based card and I am porting this to the new low cost 
Motorola EVM56K, which some of you may or not know about. I have had some 
good success and this effort now gives access to some great software 
contributions from the Alef Null group, in particular, Jarkko Vuori, 
OH2LNS. Pawel also has a wealth of good ideas that runs on M56K - I am just 
starting to appreciate some of it.

A bit more about the EVM56K: It is a small card, about the size of a TI 
DSK, has a 56002 at 40 MHz, and 3 x 32K x 8 zero wait static ram. It uses a 
Crystal Semi CS4215 CODEC and in addition, has an optional FLASH EPROM that 
allows for making it a free-standing unit. The debugger that comes 
with it uses the 56002's built in hardware debugger, called the "OnCE" port, 
and is a powerful and non-intrusive hardware/software tool. It is different 
from the TI DSK in one respect, that the OnCE does not exsist as part of the 
DSP's application program. The debugger, however, operates through the PC's 
serial line at 19.2K - a bit slow for serious development work and too 
slow for doing some of the shared DSP/host applications that we have in 
mind. If you are a Motorola fan, this is a neat piece of hardware. 

For the moment, and at least for the forseeable future, there will be 
emphasis on the PSA-type sound cards and their closely-coupled architecture 
with the PC's resources, as well as the M56K architecture. Stay tuned to 
these projects if you are interested in low-level developments.

I hope to be doing some work on the DSP-93 one of these days - though I 
am in great need of a faster intercommunication channel between the host 
and the DSP-93. If anyone has some ideas, please contact me in this regard.


Keep up the good work, 73's

--Johan, KC7WW 









From k5yfw@sacdm10.kelly.af.mil Tue Apr 18 15:20:50 1995
Received: from sacdm10.kelly.af.mil (sacdm10.kelly.af.mil [137.242.64.10]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id PAA00690 for <hfsig@tapr.org>; Tue, 18 Apr 1995 15:20:42 -0500
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2)
	id m0s1Jjh-0002BvC; Tue, 18 Apr 95 15:19 CDT
Message-Id: <m0s1Jjh-0002BvC@sacdm10.kelly.af.mil>
Date: Tue, 18 Apr 95 15:19:01 -0500
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW)
Subject: Re: [HFSIG:392] HFSIG activities
To: hfsig@tapr.org
X-orig-date: Tue, 18 Apr 1995 13:35:34 -0500
X-orig-from: "Johan Forrer" <FORRERJ@frl.orst.edu>
X-orig-message-ID: <56CCA54471@frl.orst.edu>

Johan,

For those of us runing high speed TCP/IP on the AmprNet, I don't
think anyone has found anything faster than the PI card.  Its gonna
be hard to beat a DMA card...a card plugged into the motherboard's
bus, for speed.  I believe that is part of the reason you originally
went with the Soundwave and Cardinal cards.  The Soundwave 32 can be
bought on the surplus tables for less than $75 now.

I see great benefit in off-loading some functions but keep one thing
in mind...if we are ever to gain wide acceptance of this effort, we
need to keep the effort within the confines of what computing power
that is generally available to hams without too much additional
hardware.  This is why the Baycom is so popular.

Keep up the good work.

73 to all.

Walt

In your message of 18 Apr 1995 at 1335 CDT, you write:
> Hi All,
>
> A brief update: There are considerable amount of activity going on behind
> the scenes - this mostly has to with DSP specific stuff. Adrian, G4ZHZ,
> and Pawel, SP4VRC, both are making good progress.
>
> One reality that we have to deal with is that different DSP platforms are
> being used - understandable for good reasons. I am trying to stay involved
> by cross-porting where possible. For this reason, I have been working at
> porting some of the Finnish group's (Alef Null) code. This code runs on
> a Motorola 56K-based card and I am porting this to the new low cost
> Motorola EVM56K, which some of you may or not know about. I have had some
> good success and this effort now gives access to some great software
> contributions from the Alef Null group, in particular, Jarkko Vuori,
> OH2LNS. Pawel also has a wealth of good ideas that runs on M56K - I am just
> starting to appreciate some of it.
>
> A bit more about the EVM56K: It is a small card, about the size of a TI
> DSK, has a 56002 at 40 MHz, and 3 x 32K x 8 zero wait static ram. It uses a 
> Crystal Semi CS4215 CODEC and in addition, has an optional FLASH EPROM that 
> allows for making it a free-standing unit. The debugger that comes 
> with it uses the 56002's built in hardware debugger, called the "OnCE" port, 
> and is a powerful and non-intrusive hardware/software tool. It is different 
> >from the TI DSK in one respect, that the OnCE does not exsist as part of the 
> DSP's application program. The debugger, however, operates through the PC's 
> serial line at 19.2K - a bit slow for serious development work and too 
> slow for doing some of the shared DSP/host applications that we have in 
> mind. If you are a Motorola fan, this is a neat piece of hardware. 
> 
> For the moment, and at least for the forseeable future, there will be 
> emphasis on the PSA-type sound cards and their closely-coupled architecture 
> with the PC's resources, as well as the M56K architecture. Stay tuned to 
> these projects if you are interested in low-level developments.
> 
> I hope to be doing some work on the DSP-93 one of these days - though I 
> am in great need of a faster intercommunication channel between the host 
> and the DSP-93. If anyone has some ideas, please contact me in this regard.
> 
> 
> Keep up the good work, 73's
> 
> --Johan, KC7WW 
> 
From FORRERJ@frl.orst.edu Wed Apr 19 12:32:28 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id MAA06944 for <HFSIG@tapr.org>; Wed, 19 Apr 1995 12:32:14 -0500
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id CAA22700 for <HFSIG@tapr.org>; Wed, 19 Apr 1995 02:31:34 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Wed, 19 Apr 95 10:37:54 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 19 Apr 95 10:37:35 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Wed, 19 Apr 1995 10:37:35 PST8PDT
Subject:       DSP Platforms
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <6E1137374D@frl.orst.edu>

Hi Walt,

Just some further clarifaction on DSP platforms.

For the kind of experimental work that we are doing, we need:

a) sufficient DSP cycles (the more the better),
b) sufficient bandwidth between the DSP platform and the PC.

The latter is not 100% required, but allows for exploration of closely 
coupled DSP and PC algorithms. A good example would be to let the DSP do 
real-time convolution/correlation/FFT's and use Phil's Viterbi algorithm, 
running on the PC, to steer the DSP algorithms to achieve synchronization 
and error-control. Eventually, however, one would like that to be part of a 
free-standing system, but sure helps a lot if you have access to working 
code on a PC while your are in development phases.

DMA is no real issue, however, a serial device working in the order of 115k 
or better, alternatively a high-speed parallel path is workable.
DSP sound cards happen to offer this kind of interface, and with a bit of 
additional work, the DSP-93 or EVM56K and be made to do this too.

It is my opinion that the DSP platform should not distract innovation, 
actually it adds a little "spice" to the effort - it would have been ideal 
if we all used the same hardware, but keep in mind that some of our ideas 
and contributions come from folks that do not have the financial 
means or access to technolgy that we take for granted. I think the 
appropiate thing to do is to let each use whatever they feel comfortable 
with - if it works, that is all that matters for the moment. However, in 
order to maintain some level of continuity, someone has to take on the task 
to port/translate ideas for further evaluation by others. The time  
will come when the technical details will be written up. I forsee a number 
of opportunities that will arise from that and help with that effort will be 
needed then. I guess it will be a while before we will have "turn key" 
systems - in the mean time, those that wish to be involved will have to 
roll up their sleeves and dig into the implementations themselves - its no 
simple task, but very educational, that is if one want to learn about how 
this technology works. These are exciting times.

I forgot to mention the cost of the new EVM56K - it's only $150, 
really good value for what you get - available from authorized Motorola 
dealers. I will shortly make available a software package that makes the 
EVM56K compatible with the Alef Null project and thus allows access to 
their exsisting software (LPC, various noise filters, 1200 Bell 202, 9600 
G3RUH, and DSP code for KISS/HDLC interfaces). 

We keeping on looking for help with this SIG - someone to help write 
quaterly reports for PSR and help with running the SIG. Thanks.

Remember also that TAPR membership supports this forum - if you are 
not yet a member of TAPR, kindly consider joining.

73's - keep up the good work.

Johan, KC7WW
April, 1995
From mamurphree@space.honeywell.com Wed Apr 19 13:59:34 1995
Received: from fl51mail.space.honeywell.com (fl51mail.space.honeywell.com [130.181.12.102]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id NAA07539 for <hfsig@tapr.org>; Wed, 19 Apr 1995 13:59:30 -0500
Received: from fl51p01.space.honeywell.com by fl51mail.space.honeywell.com with SMTP
	(1.38.193.5/16.2) id AA27504; Wed, 19 Apr 1995 15:03:28 -0400
Received: by smtpdos.space.honeywell.com with Microsoft Mail
	id <2F958746@smtpdos.space.honeywell.com>; Wed, 19 Apr 95 14:57:26 PDT
From: Murphree Michael A <mamurphree@space.honeywell.com>
To: hfsig <hfsig@tapr.org>
Subject: RE: [HFSIG:394] DSP Platforms
Date: Wed, 19 Apr 95 14:57:00 PDT
Message-Id: <2F958746@smtpdos.space.honeywell.com>
Encoding: 13 TEXT
X-Mailer: Microsoft Mail V3.0



>I forgot to mention the cost of the new EVM56K - it's only $150,
>really good value for what you get - available from authorized Motorola
>dealers. I will shortly make available a software package that makes the
>EVM56K compatible with the Alef Null project and thus allows access to
>their exsisting software (LPC, various noise filters, 1200 Bell 202, 9600
>G3RUH, and DSP code for KISS/HDLC interfaces).

Texas Instruments is again advertising their 3202X DSK board for $99
as well.  They do not identify exactly which processor the 2X is...

Mike N4CNW
From gjones@tenet.edu Sun Apr 23 21:39:46 1995
Received: from Alice-Thurman.tenet.edu (Alice-Thurman.tenet.edu [198.213.2.5]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id VAA12427; Sun, 23 Apr 1995 21:39:39 -0500
Received: (from gjones@localhost) by Alice-Thurman.tenet.edu (8.6.11/8.6.9) id VAA14970; Sun, 23 Apr 1995 21:39:38 -0500
From: Greg Jones <gjones@tenet.edu>
Message-Id: <199504240239.VAA14970@Alice-Thurman.tenet.edu>
Subject: TAPR @ Dayton '95
To: bbssig@tapr.org (BBS SIG mailing), netsig@tapr.org (NETSIG mailing),
        hfsig@tapr.org (HF SIG mailing), aprssig@tapr.org
Date: Sun, 23 Apr 1995 21:39:38 -0500 (CDT)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 3702      


TAPR Activities at Dayton '95
-----------------------------

Dayton is almost upon us and here is the list of TAPR activities and events
happening during Dayton.  We hope to see lots of folks around and please
stop by the TAPR booth and say hi!


TAPR Booth
----------
The booth is located at the same location as the last several years.  We
should have most items and kits available and another big membership offer
will be available to new members!  Come by and say hi to the TAPR gang and
if you want, help out behind the table.  The more the merrier.  

Regional Groups Note:  If you are with a regional digital group, please stop
by and chat with Greg Jones, WD5IVD about how TAPR can do things with your
regional group.  There will also be a place at the booth to place regional
materials, so if you have something to hand out, drop it off.


Friday - TAPR Digital Forum
---------------------------
1:00pm - 1:45pm    Introduction to Digital Communications
                      Greg Jones, WD5IVD
1:45pm - 2:00pm    TAPR Update
                      John Ackerman, AG9V
2:00pm - 2:30pm    Layer 1 and Radio Issues
                      Mel Whitten, K0PFX
2:30pm - 3:00pm    TAPR/AMSAT DSP-93 Project Update
                      Bill Reed, WD0ETZ
3:00pm - 3:30pm    TCP/IP Issues and Trends
                      Barry McLaren, VE3JF
3:30pm - 3:45pm    BBS Issues and Trends
                      Barry Buelow, WA0RJT
3:45pm - 4:00pm    HF Digital Communications Trends

4:00pm - 4:30pm    APRS
                      Bob Bruninga, WB4APR
4:30pm - 5:30pm    TAPR APRS SIG
                      Keith Sproul, WU2Z


PACK*BASH T95 - Friday Evening

------------------------------
A new event for the digitally-inclined ham, featuring:
  *  Buffet dinner (with cash bar)
  *  Nationally-known speakers holding forth on current topics:
       * Bob Bruninga, WB4APR (Author of APRS)
       * Dewayne Hendricks, WA8DZP
  *  Prize raffle
  *  Lots of Informal Discussion
  *  TAPR NET SIG and a second APRS SIG meeting

When?
  Friday evening, April 28, 1995
  Dinner starts at 7:00 PM, speaker at 7:45 PM
  Everyone is invited to attend, but dinner is only available to those
  with reservations.

Where?
  TJ's Restaurant, 2462 Dryden Road, Dayton
  (Dryden Road exit, I75 -- across from the Holiday Inn)
  (Maps available at the TAPR booth)

How?
  Dinner requires advance registration (by April 24th)
  Come by the TAPR booth at Dayton to check on additional space.
  Everyone is invited to come, but dinner is only available to those
  with reservations. 
  Dinner cost is $16.00 per person, tax and tip included.

  To register, contact: 
    TAPR (tapr@tapr.org)
    Phone: (817) 383-0000, Fax: (817) 566-2544

Who?
  PACK*BASH is co-sponsored by TAPR -- Tucson Amateur Packet Radio,
  the national leader in digital communication -- and the Miami
  Valley FM Association, Dayton's packet radio club.

(This is a replacement of the McNasty's event)


Saturday - BBS SIG Meeting
--------------------------
The TAPR BBS SIG will meet Saturday night at 7:00pm

Where:  Radison Hotel - Premier Room
        The Radison is located near the intersection of I-75 and
        Needmore Rd.  This is not far from Hara Arena.

        New feature this year - CHAIRS !!!

This is a great opportunity to meet with fellow BBS Sysops and discuss
current events and plans for the future.  TAPR membership is not a
requirement, this event is open to the public.

For more information, stop by the TAPR booth at HARA.


------------------------------------------------------------------------
Tucson Amateur Packet Radio (tapr@tapr.org)
8987-309 E Tanque Verde Rd #337 * Tucson, Az * 85749-9399 * 817-383-0000



From paulr@hagar.udc.neweast.ca Mon Apr 24 06:58:37 1995
Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id GAA14826 for <hfsig@tapr.org>; Mon, 24 Apr 1995 06:58:33 -0500
Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35)
	id AA26055; Mon, 24 Apr 95 11:58:28 GMT
Received: from cc:Mail by ccsmtp.udc.neweast.ca
	id AA798740923; Mon, 24 Apr 95 09:25:38 nst
Date: Mon, 24 Apr 95 09:25:38 nst
From: "Paul Russell" <paulr@hagar.udc.neweast.ca>
Encoding: 19 Text
Message-Id: <9503247987.AA798740923@ccsmtp.udc.neweast.ca>
To: hfsig@tapr.org
Subject: Re: [HFSIG:395] RE: DSP Platforms


>>>I forgot to mention the cost of the new EVM56K - it's only $150, 
>really good value for what you get - available from authorized Motorola
>dealers. I will shortly make available a software package that makes the 
>EVM56K compatible with the Alef Null project and thus allows access to 
>their exsisting software (LPC, various noise filters, 1200 Bell 202, 9600 
>G3RUH, and DSP code for KISS/HDLC interfaces).

Texas Instruments is again advertising their 3202X DSK board for $99 
as well.  They do not identify exactly which processor the 2X is...

Mike N4CNW<<



I'm fairly certain you can get the TMS320C5X DSK for $99. Its a fixed point DSP 
upgrade from the TMS320C26 (C25+bootloader) of the other DSK.

Paul Russell
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>>>>I forgot to mention the cost of the new EVM56K - it's only $150,
>>really good value for what you get - available from authorized Motorola
>>dealers. I will shortly make available a software package that makes the
>>EVM56K compatible with the Alef Null project and thus allows access to
>>their exsisting software (LPC, various noise filters, 1200 Bell 202, 9600
>>G3RUH, and DSP code for KISS/HDLC interfaces).
>
>Texas Instruments is again advertising their 3202X DSK board for $99
>as well.  They do not identify exactly which processor the 2X is...
>
>Mike N4CNW<<
>
>
>
>I'm fairly certain you can get the TMS320C5X DSK for $99. Its a fixed point
>DSP
>upgrade from the TMS320C26 (C25+bootloader) of the other DSK.
>
>Paul Russell
>

Actually I have two of the 320C50 DSKs that I bought when they came out.
The current ad is indicating the 20 series family though...  I never saw any
work done to translate some of the code available for the '20 DSK to the
'50 DSK.  I started to do this myself some time ago, but have not found
sufficient time to finish it.

Mike N4CNW
